| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This provides support for CP and DP relative global accesses in inline
asm.
Reviewers: robertlytton
Reviewed By: robertlytton
Differential Revision: http://llvm-reviews.chandlerc.com/D2943
llvm-svn: 203129
|
|
|
|
|
|
| |
already lives.
llvm-svn: 203046
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously for:
tail call void inttoptr (i64 65536 to void ()*)() nounwind
We would emit:
bl 65536
The immediate operand of the bl instruction is a relative offset so it is
wrong to use the absolute address here.
llvm-svn: 202860
|
|
|
|
|
|
| |
instructions.
llvm-svn: 202834
|
|
|
|
|
|
|
|
|
|
|
| |
Move the test for this class into the IR unittests as well.
This uncovers that ValueMap too is in the IR library. Ironically, the
unittest for ValueMap is useless in the Support library (honestly, so
was the ValueHandle test) and so it already lives in the IR unittests.
Mmmm, tasty layering.
llvm-svn: 202821
|
|
|
|
| |
llvm-svn: 202811
|
|
|
|
|
|
| |
Remove the old functions.
llvm-svn: 202636
|
|
|
|
| |
llvm-svn: 202621
|
|
|
|
| |
llvm-svn: 202618
|
|
|
|
|
|
|
|
|
|
| |
If a function returns a large struct by value return the first 4 words
in registers and the rest on the stack in a location reserved by the
caller. This is needed to support the xC language which supports
functions returning an arbitrary number of return values. This is
r202397 reapplied with a fix to avoid an uninitialized read of a member.
llvm-svn: 202414
|
|
|
|
|
|
| |
No functionality change. This is r202396 reapplied with no changes.
llvm-svn: 202413
|
|
|
|
|
|
| |
These are causing test failures, revert for now.
llvm-svn: 202398
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If a function returns a large struct by value return the first 4 words
in registers and the rest on the stack in a location reserved by the
caller. This is needed to support the xC language which supports
functions returning an arbitrary number of return values.
Reviewers: robertlytton
Reviewed By: robertlytton
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2889
llvm-svn: 202397
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 202396
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If the src, dst and size of a memcpy are known to be 4 byte aligned we
can call __memcpy_4() instead of memcpy().
Reviewers: robertlytton
Reviewed By: robertlytton
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2871
llvm-svn: 202395
|
|
|
|
|
|
|
| |
These instructions ignore the high bits of one of their input operands -
try and use this to simplify the code.
llvm-svn: 202394
|
|
|
|
| |
llvm-svn: 202393
|
|
|
|
| |
llvm-svn: 202172
|
|
|
|
| |
llvm-svn: 202171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The behaviour of the XCore's instruction buffer means that the performance
of the same code sequence can differ depending on whether it starts at a 4
byte aligned address or not. Since we don't model the instruction buffer
in the backend we have no way of knowing for sure if it is beneficial to
word align a specific function. However, in the absence of precise
modelling, it is better on balance to word align functions because:
* It makes a fetch-nop while executing the prologue slightly less likely.
* If we don't word align functions then a small perturbation in one
function can have a dramatic knock on effect. If the size of the function
changes it might change the alignment and therefore the performance of
all the functions that happen to follow it in the binary. This butterfly
effect makes it harder to reason about and measure the performance of
code.
llvm-svn: 202163
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r201608 made llvm corretly handle private globals with MachO. r201622 fixed
a bug in it and r201624 and r201625 were changes for using private linkage,
assuming that llvm would do the right thing.
They all got reverted because r201608 introduced a crash in LTO. This patch
includes a fix for that. The issue was that TargetLoweringObjectFile now has
to be initialized before we can mangle names of private globals. This is
trivially true during the normal codegen pipeline (the asm printer does it),
but LTO has to do it manually.
llvm-svn: 201700
|
|
|
|
|
|
|
| |
This causes the LLVMgold plugin to segfault. More information on the
replies to r201608.
llvm-svn: 201669
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The IR
@foo = private constant i32 42
is valid, but before this patch we would produce an invalid MachO from it. It
was invalid because it would use an L label in a section where the liker needs
the labels in order to atomize it.
One way of fixing it would be to just reject this IR in the backend, but that
would not be very front end friendly.
What this patch does is use an 'l' prefix in sections that we know the linker
requires symbols for atomizing them. This allows frontends to just use
private and not worry about which sections they go to or how the linker handles
them.
One small issue with this strategy is that now a symbol name depends on the
section, which is not available before codegen. This is not a problem in
practice. The reason is that it only happens with private linkage, which will
be ignored by the non codegen users (llvm-nm and llvm-ar).
llvm-svn: 201608
|
|
|
|
| |
llvm-svn: 201563
|
|
|
|
|
|
|
|
|
| |
BuildMI instructions were not including MachineMemOperand information.
This was discovered by 'SingleSource/Benchmarks/Stanford/Oscar' failing
due to a FrameIndex load incorrectly being hoisted by postra-machine-licm.
No other tests have been found to fail.
llvm-svn: 201562
|
|
|
|
| |
llvm-svn: 201561
|
|
|
|
|
|
|
|
|
|
|
|
| |
Xcore target ABI requires const data that is externally visible
to be handled differently if it has C-language linkage rather than
C++ language linkage.
Clang now emits ".cp.rodata" section information.
All other externally visible constant data will be placed in the DP section.
llvm-svn: 201144
|
|
|
|
| |
llvm-svn: 201143
|
|
|
|
|
|
|
| |
It is never null and it is not used in casts, so there is no reason to use a
pointer. This matches how we pass TM.
llvm-svn: 201025
|
|
|
|
| |
llvm-svn: 201022
|
|
|
|
|
|
| |
Clang itself was not using this. The only way to access it was via llc.
llvm-svn: 200862
|
|
|
|
| |
llvm-svn: 200345
|
|
|
|
|
|
|
|
|
| |
code to see if we're emitting a function into a non-default
text section. This is still a less-than-ideal solution, but more
contained than r199871 to determine whether or not we're emitting
code into an array of comdat sections.
llvm-svn: 200269
|
|
|
|
| |
llvm-svn: 200216
|
|
|
|
| |
llvm-svn: 200169
|
|
|
|
| |
llvm-svn: 200167
|
|
|
|
| |
llvm-svn: 200021
|
|
|
|
|
|
|
| |
Sweep the codebase for common typos. Includes some changes to visible function
names that were misspelt.
llvm-svn: 200018
|
|
|
|
|
|
|
|
|
|
|
|
| |
e.g. linkonce, to TargetMachine and set it when we've done so
for ELF targets currently. This involved making TargetMachine
non-const in a TLOF use and propagating that change around - I'm
open to other ideas.
This will be used in a future commit to handle emitting debug
information with ranges.
llvm-svn: 199871
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Representing dllexport/dllimport as distinct linkage types prevents using
these attributes on templates and inline functions.
Instead of introducing further mixed linkage types to include linkonce and
weak ODR, the old import/export linkage types are replaced with a new
separate visibility-like specifier:
define available_externally dllimport void @f() {}
@Var = dllexport global i32 1, align 4
Linkage for dllexported globals and functions is now equal to their linkage
without dllexport. Imported globals and functions must be either
declarations with external linkage, or definitions with
AvailableExternallyLinkage.
llvm-svn: 199218
|
|
|
|
|
|
|
|
| |
Revert this for now until I fix an issue in Clang with it.
This reverts commit r199204.
llvm-svn: 199207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Representing dllexport/dllimport as distinct linkage types prevents using
these attributes on templates and inline functions.
Instead of introducing further mixed linkage types to include linkonce and
weak ODR, the old import/export linkage types are replaced with a new
separate visibility-like specifier:
define available_externally dllimport void @f() {}
@Var = dllexport global i32 1, align 4
Linkage for dllexported globals and functions is now equal to their linkage
without dllexport. Imported globals and functions must be either
declarations with external linkage, or definitions with
AvailableExternallyLinkage.
llvm-svn: 199204
|
|
|
|
|
|
| |
This makes it available to tools that don't link with target (like llvm-ar).
llvm-svn: 198708
|
|
|
|
|
|
|
|
|
|
| |
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.
Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.
llvm-svn: 198685
|
|
|
|
| |
llvm-svn: 198624
|
|
|
|
|
|
| |
true.
llvm-svn: 198616
|
|
|
|
| |
llvm-svn: 198615
|
|
|
|
|
|
|
|
|
| |
This requires a knowledge of the stack size which is not known until
the frame is complete, hence the need for the XCoreFTAOElim pass
which lowers the XCoreISD::FRAME_TO_ARGS_OFFSET instrution into its
final form.
llvm-svn: 198614
|
|
|
|
|
|
| |
Only handles a depth of zero (the same as FRAMEADDR)
llvm-svn: 198613
|
|
|
|
| |
llvm-svn: 198612
|