| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
For consistency with normal instructions and clarity when reading IR,
it's best to print the %0, %1, ... names of function arguments in
definitions.
Also modifies the parser to accept IR in that form for obvious reasons.
llvm-svn: 367755
|
| |
|
|
| |
llvm-svn: 345536
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit generalizes NRVO to cover C structs (both trivial and
non-trivial structs).
rdar://problem/33599681
Differential Revision: https://reviews.llvm.org/D44968
llvm-svn: 328809
|
| |
|
|
| |
llvm-svn: 326845
|
| |
|
|
|
|
|
|
| |
EmitLifetimeStart returns a non-null `size` pointer if it actually
emits a lifetime.start. Later in this function, we use `tempSize`'s
nullness to determine whether or not we should emit a lifetime.end.
llvm-svn: 326844
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Step 1).
Summary:
Upstream LLVM is changing the the prototypes of the @llvm.memcpy/memmove/memset
intrinsics. This change updates the Clang tests for this change.
The @llvm.memcpy/memmove/memset intrinsics currently have an explicit argument
which is required to be a constant integer. It represents the alignment of the
dest (and source), and so must be the minimum of the actual alignment of the
two.
This change removes the alignment argument in favour of placing the alignment
attribute on the source and destination pointers of the memory intrinsic call.
For example, code which used to read:
call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 false)
will now read
call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false)
At this time the source and destination alignments must be the same (Step 1).
Step 2 of the change, to be landed shortly, will relax that contraint and allow
the source and destination to have different alignments.
llvm-svn: 322964
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to take type alignment padding into account whe computing physical
layouts.
The layout must be compatible with the input layout, offsets are defined in
terms of offsets within a packed struct which are computed in terms of the alloc
size of a type.
Usingthe store size we would insert padding for the following type for example:
struct {
int3 v;
long long l;
} __attribute((packed))
On x86-64 int3 is padded to int4 alignment. The swiftcc type would be
<{ <3 x float>, [4 x i8], i64 }> which is not compatible with <{ <3 x float>,
i64 }>.
The latter has i64 at offset 16 and the former at offset 20.
rdar://32618125
llvm-svn: 305956
|
| |
|
|
|
|
| |
rdar://32401301
llvm-svn: 304017
|
| |
|
|
|
|
|
|
|
|
|
| |
windows bots"
This reverts commit r284174. The tests pass for me locally. It must have
been a 2015 only crash.
Fixes PR30699
llvm-svn: 284781
|
| |
|
|
| |
llvm-svn: 284285
|
| |
|
|
|
|
|
|
|
|
|
| |
The backtrace on the bot does not give me any indication what is wrong.
The test case interestingly passes in stage2 of the build.
I don't have a way of debugging this.
Disable the test on windows and hope if there is truly a bug in the code that
was causing we will eventually run into this on other platforms.
llvm-svn: 284174
|
| |
|
|
| |
llvm-svn: 284162
|
| |
|
|
|
|
|
|
|
|
| |
Use iterator instead of address of element in vector
It is not valid to access one after the last element.
rdar://28759508
llvm-svn: 284150
|
|
|
llvm-svn: 284133
|
