This method emits nodes for passing byval arguments in registers and stack.
This has the same functionality as existing functions PassByValArg64 and
WriteByValArg which will be deleted later.
llvm-svn: 166843
This method copies byval arguments passed in registers onto the stack and has
the same functionality as existing functions CopyMips64ByValRegs and
ReadByValArg which will be deleted later.
llvm-svn: 166841
Add getCostXXX calls for different families of opcodes, such as casts, arithmetic, cmp, etc.
Port the LoopVectorizer to the new API.
The LoopVectorizer now finds instructions which will remain uniform after vectorization. It uses this information when calculating the cost of these instructions.
llvm-svn: 166836
Keep the integer_insertelement test case, the new coalescer can handle
this kind of lane insertion without help from pseudo-instructions.
llvm-svn: 166835
doesn't include padding up to the alignment of the record, take this
as a cue that the alignment of the record should (conservatively) be
set to 1. This is similar to other the other cues we use to determine
that the record has a lower alignment, e.g., that the
externally-supplied layout places fields at lower offsets than we
would. Fixes <rdar://problem/12582052>; test case in LLDB.
llvm-svn: 166824
extern "C", its method definitions must be IRGen'ed
before meta-data for class is generated. Otherwise,
IRGen crashes (to say the least).
// rdar://12581683
llvm-svn: 166809
varargs parameter passing.
A strict reading of the ABI indicates that any argument with alignment greater
than 8 may require skipping doublewords in the parameter save area to align
the argument, and hence require skipping GPRs. In practice, this is not done
by GCC. The alignment restriction is used for internal alignment of a
structure, but a structure with 16-byte alignment, for example, is not
itself 16-byte aligned in the parameter save area. Although this is messy,
it has become the de facto standard used in building existing libraries.
My initial varargs support followed the ABI language, but not the de facto
standard. Running the GCC compatibility test suite exposed this issue, and
indeed showed that LLVM didn't pass parameters self-consistently with my
original logic. Removing the additional alignment logic allows the affected
tests to now pass.
I modified the ppc64-varargs-struct.c test case to remove the existing test
for generation of alignment code, which is no longer appropriate.
Built and tested on powerpc64-unknown-linux-gnu with no new regressions.
llvm-svn: 166805
APInt::shl generated llvm.trap to guard against shifts greater than bit-width.
This was already checked with an assert, and there was a special case for
shifts equal to bit-width. Modify this check to catch shifts greater than or
equal to bit-width, so llvm.trap isn't generated.
Patch contributed by JF Bastien
llvm-svn: 166803
The subtle behavior is that the Predicate wait functions may not detect transitory changes in the predicate value. Consider the following scenario.
Thread A waits for a bit to be set in the predicate value.
Thread B sets the bit in the predicate value.
Before Thread A wakes up, Thread C clears the bit in the predicate value.
Thread A wakes, checks the value and goes back to waiting.
The mutex and condition variables protect access to the value, but they offer no guarantee that another thread will not acquire the mutex and change the value before a waiting thread is restarted after a change.
I believe that the current behavior is correct and reasonable. I just want to leave a marker to prevent possible problems in the future or to help anyone who might be unfortunate enough to encounter such a problem.
llvm-svn: 166800
Rafael Espindola