| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
(so that it can have additional options set when trying to debug issues causing regressions).
llvm-svn: 166681
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
structs having size 3, 5, 6, or 7. Such a struct must be passed and received
as right-justified within its register or memory slot. The problem is only
present for structs that are passed in registers.
Previously, as part of a patch handling all structs of size less than 8, I
added logic to rotate the incoming register so that the struct was left-
justified prior to storing the whole register. This was incorrect because
the address of the parameter had already been adjusted earlier to point to
the right-adjusted value in the storage slot. Essentially I had accidentally
accounted for the right-adjustment twice.
In this patch, I removed the incorrect logic and reorganized the code to make
the flow clearer.
The removal of the rotates changes the expected code generation, so test case
structsinregs.ll has been modified to reflect this. I also added a new test
case, jaggedstructs.ll, to demonstrate that structs of these sizes can now
be properly received and passed.
I've built and tested the code on powerpc64-unknown-linux-gnu with no new
regressions. I also ran the GCC compatibility test suite and verified that
earlier problems with these structs are now resolved, with no new regressions.
llvm-svn: 166680
|
| |
|
|
|
|
|
|
| |
variables when using a gnueabihf or aapcs-vfp target.
Tested by me and Wei-Ren Chen.
llvm-svn: 166679
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds initial support for MCJIT for PPC64-elf-abi. The TOC
relocation and ODP handling is implemented.
It fixes the following ExecutionEngine testcases:
ExecutionEngine/2003-01-04-ArgumentBug.ll
ExecutionEngine/2003-01-04-LoopTest.ll
ExecutionEngine/2003-01-04-PhiTest.ll
ExecutionEngine/2003-01-09-SARTest.ll
ExecutionEngine/2003-01-10-FUCOM.ll
ExecutionEngine/2003-01-15-AlignmentTest.ll
ExecutionEngine/2003-05-11-PHIRegAllocBug.ll
ExecutionEngine/2003-06-04-bzip2-bug.ll
ExecutionEngine/2003-06-05-PHIBug.ll
ExecutionEngine/2003-08-15-AllocaAssertion.ll
ExecutionEngine/2003-08-21-EnvironmentTest.ll
ExecutionEngine/2003-08-23-RegisterAllocatePhysReg.ll
ExecutionEngine/2003-10-18-PHINode-ConstantExpr-CondCode-Failure.ll
ExecutionEngine/simplesttest.ll
ExecutionEngine/simpletest.ll
ExecutionEngine/stubs.ll
ExecutionEngine/test-arith.ll
ExecutionEngine/test-branch.ll
ExecutionEngine/test-call-no-external-funcs.ll
ExecutionEngine/test-cast.ll
ExecutionEngine/test-common-symbols.ll
ExecutionEngine/test-constantexpr.ll
ExecutionEngine/test-fp-no-external-funcs.ll
ExecutionEngine/test-fp.ll
ExecutionEngine/test-global-init-nonzero.ll
ExecutionEngine/test-global.ll
ExecutionEngine/test-loadstore.ll
ExecutionEngine/test-local.ll
ExecutionEngine/test-logical.ll
ExecutionEngine/test-loop.ll
ExecutionEngine/test-phi.ll
ExecutionEngine/test-ret.ll
ExecutionEngine/test-return.ll
ExecutionEngine/test-setcond-fp.ll
ExecutionEngine/test-setcond-int.ll
ExecutionEngine/test-shift.ll
llvm-svn: 166678
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds initial PPC64 TOC MC object creation using the small mcmodel
(a single 64K TOC) adding the some TOC relocations (R_PPC64_TOC,
R_PPC64_TOC16, and R_PPC64_TOC16DS).
The addition of 'undefinedExplicitRelSym' hook on 'MCELFObjectTargetWriter'
is meant to avoid the creation of an unreferenced ".TOC." symbol (used in
the .odp creation) as well to set the R_PPC64_TOC relocation target as the
temporary ".TOC." symbol. On PPC64 ABI, the R_PPC64_TOC relocation should
not point to any symbol.
llvm-svn: 166677
|
| |
|
|
|
|
| |
and are generated by Clang (global initializers/destructors, thunks) . Fixes PR13942.
llvm-svn: 166676
|
| |
|
|
|
|
| |
newFrontendActionFactory.InjectsEndOfSourceFileCallback on Win32 for now. Investigating.
llvm-svn: 166674
|
| |
|
|
|
|
|
|
| |
translation unit is processed.
This is important when one wants to deduplicate results during one run over a translation unit by pointer identity of AST nodes.
llvm-svn: 166671
|
| |
|
|
|
|
|
| |
I like to make w/o being able to build, but I don't have the dependencies to
build and test polly. I'll revert if the build bots don't like it.
llvm-svn: 166670
|
| |
|
|
|
|
| |
added -mcpu flag, may be it will fix the problem
llvm-svn: 166669
|
| |
|
|
| |
llvm-svn: 166668
|
| |
|
|
| |
llvm-svn: 166666
|
| |
|
|
| |
llvm-svn: 166665
|
| |
|
|
| |
llvm-svn: 166664
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
smaller integer loads and stores.
The high-level motivation is that the frontend sometimes generates
a single whole-alloca integer load or store during ABI lowering of
splittable allocas. We need to be able to break this apart in order to
see the underlying elements and properly promote them to SSA values. The
hope is that this fixes some performance regressions on x86-32 with the
new SROA pass.
Unfortunately, this causes quite a bit of churn in the test cases, and
bloats some IR that comes out. When we see an alloca that consists soley
of bits and bytes being extracted and re-inserted, we now do some
splitting first, before building widened integer "bucket of bits"
representations. These are always well folded by instcombine however, so
this shouldn't actually result in missed opportunities.
If this splitting of all-integer allocas does cause problems (perhaps
due to smaller SSA values going into the RA), we could potentially go to
some extreme measures to only do this integer splitting trick when there
are non-integer component accesses of an alloca, but discovering this is
quite expensive: it adds yet another complete walk of the recursive use
tree of the alloca.
Either way, I will be watching build bots and LNT bots to see what
fallout there is here. If anyone gets x86-32 numbers before & after this
change, I would be very interested.
llvm-svn: 166662
|
| |
|
|
|
|
| |
CodeGen side.
llvm-svn: 166661
|
| |
|
|
| |
llvm-svn: 166660
|
| |
|
|
|
|
| |
when computing the size of the precompiled preamble.
llvm-svn: 166659
|
| |
|
|
|
|
| |
reflect a change to the initializer.
llvm-svn: 166657
|
| |
|
|
| |
llvm-svn: 166656
|
| |
|
|
| |
llvm-svn: 166655
|
| |
|
|
|
|
|
| |
replaced by the more efficient, cleaner preprocessor-option version
that occurs earlier in PCH validation.
llvm-svn: 166654
|
| |
|
|
|
|
| |
checking, and disable the old predefines-buffer-diff'ing code path.
llvm-svn: 166653
|
| |
|
|
|
|
|
| |
use a DynamicLoaderStatic dynamic loader for the session
instead of a kernel or user dynamic loader.
llvm-svn: 166652
|
| |
|
|
|
|
|
|
| |
correct IR type.
Reported in the thread "devirtualisation appears to crash clang on covariant functions on ARM" on cfe-dev.
llvm-svn: 166651
|
| |
|
|
| |
llvm-svn: 166650
|
| |
|
|
|
|
| |
Patch by Paul Redmond <paul.redmond@intel.com>.
llvm-svn: 166649
|
| |
|
|
|
|
|
| |
predefines. We're not quite ready to cut over to these suggested
predefines yet, however.
llvm-svn: 166648
|
| |
|
|
|
|
|
| |
modifiers. (From an idea by Eric...)
<rdar://problem/12284092>
llvm-svn: 166647
|
| |
|
|
| |
llvm-svn: 166646
|
| |
|
|
|
|
| |
this, for better error recovery.
llvm-svn: 166645
|
| |
|
|
|
|
| |
rebuilds a function type, and that function type has parens around its name.
llvm-svn: 166644
|
| |
|
|
| |
llvm-svn: 166643
|
| |
|
|
| |
llvm-svn: 166642
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the macros that are #define'd or #undef'd on the command line. This
checking happens much earlier than the current macro-definition
checking and is far cleaner, because it does a direct comparison
rather than a diff of the predefines buffers. Moreover, it allows us
to use the result of this check to skip over PCH files within a
directory that have non-matching -D's or -U's on the command
line. Finally, it improves the diagnostics a bit for mismatches,
fixing <rdar://problem/8612222>.
The old predefines-buffer diff'ing will go away in a subsequent commit.
llvm-svn: 166641
|
| |
|
|
| |
llvm-svn: 166640
|
| |
|
|
| |
llvm-svn: 166639
|
| |
|
|
|
|
|
| |
correct .s output as well as get the correct encoding by the integrated
assembler.
llvm-svn: 166638
|
| |
|
|
| |
llvm-svn: 166637
|
| |
|
|
|
| |
FIXME: They are still long strings without formatter in printf(3)!
llvm-svn: 166636
|
| |
|
|
|
|
|
|
|
| |
to dotest.py so that the testsuite can run against
any LLDB.
<rdar://problem/12512268>
llvm-svn: 166635
|
| |
|
|
| |
llvm-svn: 166634
|
| |
|
|
| |
llvm-svn: 166633
|
| |
|
|
|
|
|
|
|
|
|
|
| |
[register].field
The operator returns the value at the location pointed to by register plus the
offset of field within its structure or union. This patch only handles
immediate fields (i.e., [eax].4). The original displacement has to be a
MCConstantExpr as well.
Part of rdar://12470415 and rdar://12470514
llvm-svn: 166632
|
| |
|
|
|
|
| |
rules for sign-extension in GetValueAsUnsigned()
llvm-svn: 166631
|
| |
|
|
| |
llvm-svn: 166630
|
| |
|
|
|
|
| |
SetTheory, but pass down the location explicitly.
llvm-svn: 166629
|
| |
|
|
| |
llvm-svn: 166628
|
| |
|
|
| |
llvm-svn: 166627
|
| |
|
|
|
|
| |
type promotion
llvm-svn: 166626
|