| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
llvm::GLobalVariable name may not match user visibile name for function static variables.
llvm-svn: 102644
|
| |
|
|
|
|
|
|
| |
IEEE-754, e.g.,
NAN != NAN ? 1 : 0 should return 1. Also fix the case for complex.
llvm-svn: 102598
|
| |
|
|
|
|
| |
incomplete type. Fixes PR6911.
llvm-svn: 102473
|
| |
|
|
|
|
|
|
| |
input and output types when the smaller value isn't mentioned in the
asm string. Extend this support from integers to also allowing
fp values to be mismatched (if not mentioned in the asm string).
llvm-svn: 102188
|
| |
|
|
| |
llvm-svn: 102182
|
| |
|
|
|
|
| |
variants. This fixes neon inline asm which my patch for PR6780 broke.
llvm-svn: 102181
|
| |
|
|
|
|
|
|
|
|
|
| |
- This fixes the last known ABI issues with ARM/APCS.
- I've run the first 1k ABITests with '--no-unsigned --no-vector --no-complex'
on {armv6, armv7} x {-mno-thumb, -mthumb}, and the first 10k tests for armv7
-mthumb, for both function return types and single argument calls. These all
pass now (they failed horribly before without --no-bitfield).
llvm-svn: 102070
|
| |
|
|
|
|
|
| |
immediately narrowed the access size. Fix this (and previous case) by just
choosing a better access size up-front.
llvm-svn: 102068
|
| |
|
|
|
|
|
| |
we have to narrow the access side immediately (can happen with packed,
-fno-bitfield-type-align).
llvm-svn: 102067
|
| |
|
|
| |
llvm-svn: 102046
|
| |
|
|
|
|
|
|
|
|
|
|
| |
of the structure, which we also now verify as part of the post-layout consistency checks.
- This fixes some pedantic bugs with packed structures, as well as major problems with -fno-bitfield-type-align.
- Fixes PR5591, PR5567, and all known -fno-bitfield-type-align issues.
- Review appreciated.
llvm-svn: 102045
|
| |
|
|
|
|
| |
exceeds the minimum ABI alignment.
llvm-svn: 102019
|
| |
|
|
| |
llvm-svn: 102018
|
| |
|
|
| |
llvm-svn: 102016
|
| |
|
|
|
|
|
| |
matches how we currently handle structs, and this correctly handles
-fno-bitfield-type-align.
llvm-svn: 101918
|
| |
|
|
|
|
|
|
|
| |
This mirror's Dan's patch for llvm-gcc in r97989, and
fixes the miscompilation in PR6525. There is some contention
over whether this is the right thing to do, but it is the
conservative answer and demonstrably fixes a miscompilation.
llvm-svn: 101877
|
| |
|
|
|
|
| |
as a side-effect, remove two FIXMEs now fixed
llvm-svn: 101726
|
| |
|
|
| |
llvm-svn: 101678
|
| |
|
|
|
|
|
|
|
|
| |
void exit_picture()
{
char yuv_types[4][6]= {"4:0:0","4:2:0","4:2:2","4:4:4"};
foo(yuv_types);
}
llvm-svn: 101623
|
| |
|
|
| |
llvm-svn: 101568
|
| |
|
|
|
|
| |
this follows from C99 6.7.8p10: if it is a union, the first named member is initialized
llvm-svn: 101539
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
struct may cause it to shrink more than one byte. Before
my recent changes we compiled the new test into:
%0 = type { [6 x i8] }
@x = global %0 { [6 x i8] undef }, align 2 ; <%0*> [#uses=0]
which is obviously bogus. Now we compile it into:
%0 = type <{ i32, i8, i8 }>
@x = global %0 zeroinitializer, align 2 ; <%0*> [#uses=0]
Where the last byte only is tail padding.
llvm-svn: 101536
|
| |
|
|
|
|
| |
merge also a few tests I had here for this feature, and FileCheck'ize one file
llvm-svn: 101535
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
|
| |
|
|
|
|
|
|
|
| |
Stop multiplying constant by 8 accordingly in the header and change
intrinsic definition for what types we expect.
Add to existing palignr test to check that we're emitting the correct things.
llvm-svn: 101332
|
| |
|
|
|
|
| |
Anton Yartsev!
llvm-svn: 101281
|
| |
|
|
|
|
| |
CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.", I think it might be breaking bootstrap.
llvm-svn: 101235
|
| |
|
|
|
|
|
|
|
|
| |
CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
llvm-svn: 101222
|
| |
|
|
| |
llvm-svn: 101215
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
elements with explicit zero values instead of with tail padding.
On an example like this:
struct foo { int a; int b; };
struct foo fooarray[] = {
{1, 2},
{4},
};
We now lay this out as:
@fooarray = global [2 x %struct.foo] [%struct.foo { i32 1, i32 2 }, %struct.foo { i32 4, i32 0 }]
instead of as:
@fooarray = global %0 <{ %struct.foo { i32 1, i32 2 }, %1 { i32 4, [4 x i8] zeroinitializer } }>
Preserving both the struct type of the second element, but also the array type of the entire thing.
llvm-svn: 101155
|
| |
|
|
|
|
|
|
| |
trailing fields may not be represented in initializer lists, they
are being handled as padding and those fields *must* be zero
initialized.
llvm-svn: 101067
|
| |
|
|
| |
llvm-svn: 100962
|
| |
|
|
| |
llvm-svn: 100938
|
| |
|
|
|
|
|
|
| |
to the intrinsic, even when math-errno is off.
Fixes rdar://problem/7828230 by falling back on the library function.
llvm-svn: 100613
|
| |
|
|
|
|
| |
that the integrated assembler is working.
llvm-svn: 100545
|
| |
|
|
| |
llvm-svn: 100449
|
| |
|
|
|
|
| |
field to memcpy, memmove, and memset.
llvm-svn: 100305
|
| |
|
|
| |
llvm-svn: 100236
|
| |
|
|
| |
llvm-svn: 100235
|
| |
|
|
| |
llvm-svn: 100200
|
| |
|
|
|
|
| |
field to memcpy, memmove, and memset.
llvm-svn: 100193
|
| |
|
|
|
|
| |
instruction.
llvm-svn: 99962
|
| |
|
|
| |
llvm-svn: 99960
|
| |
|
|
| |
llvm-svn: 99949
|
| |
|
|
|
|
| |
Fixes PR3782.
llvm-svn: 99940
|
| |
|
|
|
|
|
|
| |
double 0.000000e+000
instead of
double 0.000000e+00
llvm-svn: 99932
|
| |
|
|
|
|
| |
memmove, and memset
llvm-svn: 99930
|
| |
|
|
|
|
|
|
| |
This introduces FunctionType::ExtInfo to hold the calling convention and the
noreturn attribute. The next patch will extend it to include the regparm
attribute and fix the bug.
llvm-svn: 99920
|
| |
|
|
|
|
|
| |
instead of the canonical parameter type (which has correctly dropped all such
direct qualifiers). Fixes PR6695.
llvm-svn: 99688
|
| |
|
|
| |
llvm-svn: 99616
|