| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
llvm-svn: 171369
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
generally support the C++11 memory model requirements for bitfield
accesses by relying more heavily on LLVM's memory model.
The primary change this introduces is to move from a manually aligned
and strided access pattern across the bits of the bitfield to a much
simpler lump access of all bits in the bitfield followed by math to
extract the bits relevant for the particular field.
This simplifies the code significantly, but relies on LLVM to
intelligently lowering these integers.
I have tested LLVM's lowering both synthetically and in benchmarks. The
lowering appears to be functional, and there are no really significant
performance regressions. Different code patterns accessing bitfields
will vary in how this impacts them. The only real regressions I'm seeing
are a few patterns where the LLVM code generation for loads that feed
directly into a mask operation don't take advantage of the x86 ability
to do a smaller load and a cheap zero-extension. This doesn't regress
any benchmark in the nightly test suite on my box past the noise
threshold, but my box is quite noisy. I'll be watching the LNT numbers,
and will look into further improvements to the LLVM lowering as needed.
llvm-svn: 169489
|
|
|
|
| |
llvm-svn: 163983
|
|
|
|
| |
llvm-svn: 159295
|
|
|
|
|
|
| |
patch by Jon Mulder!
llvm-svn: 135851
|
|
|
|
| |
llvm-svn: 135577
|
|
|
|
| |
llvm-svn: 134831
|
|
|
|
|
|
| |
intended.
llvm-svn: 130087
|
|
|
|
|
|
| |
functionality intended.
llvm-svn: 130085
|
|
|
|
|
|
|
|
|
|
|
|
| |
a zero constant for a complete class. rdar://problem/8424975
To make this happen, track the field indexes for virtual bases
in the complete object. I'm curious whether we might be better
off making CGRecordLayoutBuilder *much* more reliant on
ASTRecordLayout; we're currently duplicating an awful lot of the ABI
layout logic.
llvm-svn: 125555
|
|
|
|
|
|
|
| |
refer to opaque types, they must be held via PATypeHolders. I'm
not sure why this hasn't blown up before.
llvm-svn: 120491
|
|
|
|
| |
llvm-svn: 120106
|
|
|
|
| |
llvm-svn: 119956
|
|
|
|
|
|
| |
a first step towards fixing PR6995.
llvm-svn: 118491
|
|
|
|
|
|
| |
functions.
llvm-svn: 112913
|
|
|
|
|
|
|
|
|
| |
Make CGT defer to the ABI on all member pointer types.
This requires giving CGT a handle to the ABI.
It's way easier to make that work if we avoid lazily creating the ABI.
Make it so.
llvm-svn: 111786
|
|
|
|
| |
llvm-svn: 104013
|
|
|
|
| |
llvm-svn: 102429
|
|
|
|
|
|
|
|
| |
arguments, it is now an immutable object.
Also, add some checking of various invariants that should hold on the CGBitFieldInfo access.
llvm-svn: 101345
|
|
|
|
| |
llvm-svn: 101344
|
|
|
|
| |
llvm-svn: 101221
|
|
|
|
|
|
|
|
|
|
| |
"policy" with which a bit-field should be accessed.
- For now, these policies are computed to match the current IRgen strategy, although the new information isn't being used yet (except in -fdump-record-layouts).
- Design comments appreciated.
llvm-svn: 101178
|
|
|
|
|
|
| |
-fdump-record-layouts.
llvm-svn: 101051
|
|
|
|
|
|
| |
bit-field LValues to just store the base address of object containing the bit-field.
llvm-svn: 100745
|
|
|
|
| |
llvm-svn: 100513
|
|
|
|
| |
llvm-svn: 100433
|
|
|
|
|
|
|
|
| |
of CodeGenTypes, to per-record CGRecordLayout structures.
- I did a cursory check that this was perf neutral, FWIW.
llvm-svn: 99978
|
|
|
|
| |
llvm-svn: 99967
|
|
llvm-svn: 99945
|