diff options
author | Alex Bradbury <asb@lowrisc.org> | 2020-06-12 10:26:53 +0100 |
---|---|---|
committer | Alex Bradbury <asb@lowrisc.org> | 2020-06-12 10:33:47 +0100 |
commit | 3dcfd482cb17fad2d641c976b822d1fe36dc1359 (patch) | |
tree | 024ef1468e32c332bfee8930aa6fb55ec3a2669c /clang/lib/Frontend/CompilerInvocation.cpp | |
parent | f257c2138f5e771bad7ff5f6bccf8ba190f4e501 (diff) | |
download | llvm-3dcfd482cb17fad2d641c976b822d1fe36dc1359.zip llvm-3dcfd482cb17fad2d641c976b822d1fe36dc1359.tar.gz llvm-3dcfd482cb17fad2d641c976b822d1fe36dc1359.tar.bz2 |
[CodeGen] Increase applicability of ffine-grained-bitfield-accesses for targets with limited native integer widths
As pointed out in PR45708, -ffine-grained-bitfield-accesses doesn't
trigger in all cases you think it might for RISC-V. The logic in
CGRecordLowering::accumulateBitFields checks OffsetInRecord is a legal
integer according to the datalayout. RISC targets will typically only
have the native width as a legal integer type so this check will fail
for OffsetInRecord of 8 or 16 when you would expect the transformation
is still worthwhile.
This patch changes the logic to check for an OffsetInRecord of a at
least 1 byte, that fits in a legal integer, and is a power of 2. We
would prefer to query whether native load/store operations are
available, but I don't believe that is possible.
Differential Revision: https://reviews.llvm.org/D79155
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions