llvm-svn: 166053

We generalize r166040 to handle ABI alignment issues for all types.

rdar://12439123

llvm-svn: 166052

llvm-svn: 166051

llvm-svn: 166050

llvm-svn: 166049

llvm-svn: 166048

@implementation.

llvm-svn: 166047

llvm+clang+compiler-rt bootstrap.

llvm-svn: 166046

llvm-svn: 166045

We expand varargs in clang and the call site is handled in the back end, it is
hard to match exactly how illegal vectors are handled in the backend. Therefore,
we legalize the illegal vector types in clang:
if (Size <= 32), legalize to i32.
if (Size == 64), legalize to v2i32.
if (Size == 128), legalize to v4i32.
if (Size > 128), use indirect.

rdar://12439123

llvm-svn: 166043

We create an aligned temporary space and copy the content over from ap.cur to
the temporary space. This is necessary if the natural alignment of the type is
greater than the ABI alignment.

rdar://12439123

llvm-svn: 166040

This implementation doesn't warn on anything that GCC doesn't warn on with the
exception of templates specializations (GCC doesn't warn, Clang does). The
specific skipped cases (boolean, constant expressions, enums) are open for
debate/adjustment if anyone wants to demonstrate that GCC is being overly
conservative here. The only really obvious false positive I found was in the
Clang regression suite's MPI test - apparently MPI uses specific flag values in
pointer constants. (eg: #define FOO (void*)~0)

llvm-svn: 166039

command line to dotest.py, replace / with _ in
the logfile names that mention that compiler so
that we don't try to put log files in weird
places.

llvm-svn: 166038

llvm-svn: 166037

- Add custom FP_TO_SINT on v8i16 (and v8i8 which is legalized as v8i16 due to
  vector element-wise widening) to reduce DAG combiner and its overhead added
  in X86 backend.

llvm-svn: 166036

llvm-svn: 166035

don't try the normal GetOrCreateLLVM. The latter could drop the weak
atrtibute on the second reference, if there is no explicit declaration
of the aliasee.

llvm-svn: 166032

Speculative fix the mask constants to be of type uintptr_t.  I don't know of any case where the old form was incorrect, but I'm more confident that such cases don't exist in this version.

llvm-svn: 166031

// rdar://12491143

llvm-svn: 166030

Fixes http://code.google.com/p/address-sanitizer/issues/detail?id=122

llvm-svn: 166029

llvm-svn: 166028

llvm-svn: 166026

hopelessly poorly written code after spewing several
errors. // rdar://12491143

llvm-svn: 166025

llvm-svn: 166024

metadata.

llvm-svn: 166023

For the PowerPC 64-bit ELF Linux ABI, aggregates of size less than 8
bytes are to be passed in the low-order bits ("right-adjusted") of the
doubleword register or memory slot assigned to them.  A previous patch
addressed this for aggregates passed in registers.  However, small
aggregates passed in the overflow portion of the parameter save area are
still being passed left-adjusted.

The fix is made in PPCTargetLowering::LowerCall_Darwin_Or_64SVR4 on the
caller side, and in PPCTargetLowering::LowerFormalArguments_64SVR4 on
the callee side.  The main fix on the callee side simply extends
existing logic for 1- and 2-byte objects to 1- through 7-byte objects,
and correcting a constant left over from 32-bit code.  There is also a
fix to a bogus calculation of the offset to the following argument in
the parameter save area.

On the caller side, again a constant left over from 32-bit code is
fixed.  Additionally, some code for 1, 2, and 4-byte objects is
duplicated to handle the 3, 5, 6, and 7-byte objects for SVR4 only.  The
LowerCall_Darwin_Or_64SVR4 logic is getting fairly convoluted trying to
handle both ABIs, and I propose to separate this into two functions in a
future patch, at which time the duplication can be removed.

The patch adds a new test (structsinmem.ll) to demonstrate correct
passing of structures of all seven sizes.  Eight dummy parameters are
used to force these structures to be in the overflow portion of the
parameter save area.

As a side effect, this corrects the case when aggregates passed in
registers are saved into the first eight doublewords of the parameter
save area:  Previously they were stored left-justified, and now are
properly stored right-justified.  This requires changing the expected
output of existing test case structsinregs.ll.

llvm-svn: 166022

The bug was within isl. To fix it, we simply update the isl version that
is used by Polly. We still have some changes within Polly to be able to
write a proper test case.

Reported-by: Sameer Sahasrabuddhe <Sameer.Sahasrabuddhe@amd.com>
llvm-svn: 166021

Previously isl always generated '<=' or '>='. However, in many cases '<' or '>'
leads to simpler code. This commit updates isl and adds the relevant code
generation support to Polly.

llvm-svn: 166020

  if (CGM.getModuleDebugInfo())
    DebugInfo = CGM.getModuleDebugInfo()
into a call:
  maybeInitializeDebugInfo();

This is a simplification for a possible future fix of PR13942.

llvm-svn: 166019

Stack is formed improperly for long structures passed as byval arguments for
EABI mode.

If we took AAPCS reference, we can found the next statements:

A: "If the argument requires double-word alignment (8-byte), the NCRN (Next
Core Register Number) is rounded up to the next even register number." (5.5
Parameter Passing, Stage C, C.3).

B: "The alignment of an aggregate shall be the alignment of its most-aligned
component." (4.3 Composite Types, 4.3.1 Aggregates).

So if we have structure with doubles (9 double fields) and 3 Core unused
registers (r1, r2, r3): caller should use r2 and r3 registers only.
Currently r1,r2,r3 set is used, but it is invalid.

Callee VA routine should also use r2 and r3 regs only. All is ok here. This
behaviour is guessed by rounding up SP address with ADD+BFC operations.

Fix:
Main fix is in ARMTargetLowering::HandleByVal. If we detected AAPCS mode and
8 byte alignment, we waste odd registers then.

P.S.:
I also improved LDRB_POST_IMM regression test. Since ldrb instruction will
not generated by current regression test after this patch. 

llvm-svn: 166018

Original message:

The attached is the fix to radar://11663049. The optimization can be outlined by following rules:

   (select (x != c), e, c) -> select (x != c), e, x),
   (select (x == c), c, e) -> select (x == c), x, e)
where the <c> is an integer constant.

 The reason for this change is that : on x86, conditional-move-from-constant needs two instructions;
however, conditional-move-from-register need only one instruction.

  While the LowerSELECT() sounds to be the most convenient place for this optimization, it turns out to be a bad place. The reason is that by replacing the constant <c> with a symbolic value, it obscure some instruction-combining opportunities which would otherwise be very easy to spot. For that reason, I have to postpone the change to last instruction-combining phase.

  The change passes the test of "make check-all -C <build-root/test" and "make -C project/test-suite/SingleSource".

Original message since r165661:

My previous change has a bug: I negated the condition code of a CMOV, and go ahead creating a new CMOV using the *ORIGINAL* condition code.

llvm-svn: 166017

llvm-svn: 166016

Fix a bug in the set(I,E)/reset(I,E) methods that I recently added.  The boundary condition for checking if I and E were in the same word were incorrect, and, beyond that, the mask computation was not using a wide enough constant.

llvm-svn: 166015

llvm-svn: 166014

llvm-svn: 166013

llvm-svn: 166012

llvm-svn: 166011

Use the Attributes::get method which takes an AttrVal value directly to simplify the code a bit. No functionality change.

llvm-svn: 166010

Use the Attributes::get method which takes an AttrVal value directly to simplify the code a bit. No functionality change.

llvm-svn: 166009

llvm-svn: 166008