Eventually DataLayoutPass should go away, but for now that is the only easy
way to get a DataLayout in some APIs. This patch only changes the ones that
have easy access to a Module.
One interesting issue with sometimes using DataLayoutPass and sometimes
fetching it from the Module is that we have to make sure they are equivalent.
We can get most of the way there by always constructing the pass with a Module.
In fact, the pass could be changed to point to an external DataLayout instead
of owning one to make this stricter.
Unfortunately, the C api passes a DataLayout, so it has to be up to the caller
to make sure the pass and the module are in sync.
llvm-svn: 202204
No tool does this currently, but as everything else in a module we should be
able to change its DataLayout.
Most of the fix is in DataLayout to make sure it can be reset properly.
The test uses Module::setDataLayout since the fact that we mutate a DataLayout
is an implementation detail. The module could hold a OwningPtr<DataLayout> and
the DataLayout itself could be immutable.
Thanks to Philip Reames for pushing me in the right direction.
llvm-svn: 202198
Now that DataLayout is not a pass, store one in Module.
Since the C API expects to be able to get a char* to the datalayout description,
we have to keep a std::string somewhere. This patch keeps it in Module and also
uses it to represent modules without a DataLayout.
Once DataLayout is mandatory, we should probably move the string to DataLayout
itself since it won't be necessary anymore to represent the special case of a
module without a DataLayout.
llvm-svn: 202190
Variadic functions have an unspecified parameter tag after the last
argument. In IR this is represented as an unspecified parameter in the
subroutine type.
Paired commit with CFE r202185.
rdar://problem/13690847
This re-applies r202184 + a bugfix in DwarfDebug's argument handling.
llvm-svn: 202188
Variadic functions have an unspecified parameter tag after the last
argument. In IR this is represented as an unspecified parameter in the
subroutine type.
Paired commit with CFE.
rdar://problem/13690847
llvm-svn: 202184
These complement many of the existing accessors and make it
significantly easier to write code which needs to poke at the underlying
Use without hard coding the operand number at which it resides for
a particular instruction. No functionality changed of course.
llvm-svn: 202102
After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)
llvm-svn: 202052
Before this patch they would take an boolean argument to say if the path
already existed. This was redundant with the returned error_code which is able
to represent that. This allowed for callers to incorrectly check only the
existed flag instead of first checking the error code.
Instead, pass in a boolean flag to say if the previous (non-)existence should be
an error or not.
Callers of the of the old simple versions are not affected. They still ignore
the previous (non-)existence as they did before.
llvm-svn: 201979
This commit moves getSLEB128Size() and getULEB128Size() from
MCAsmInfo to LEB128.h and removes some copy-and-paste code.
Besides, this commit also adds some unit tests for the LEB128
functions.
llvm-svn: 201937
The operator+() and operator-() do not change the member
variables of SuccIterator. This CL will qualify the *this*
pointer with const.
llvm-svn: 201933
CodeGenPrepare uses extensively TargetLowering which is part of libLLVMCodeGen.
This is a layer violation which would introduce eventually a dependence on
CodeGen in ScalarOpts.
Move CodeGenPrepare into libLLVMCodeGen to avoid that.
Follow-up of <rdar://problem/15519855>
llvm-svn: 201912
This interface allows IRObjectFile to be implemented without having dummy
methods for all section and segment related methods.
Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is
still not plugged in since it requires some refactoring to make a Module hold
a DataLayout.
llvm-svn: 201881
This replaces the old NoIntegratedAssembler with at TargetOption. This is
more flexible and will be used to forward clang's -no-integrated-as option.
llvm-svn: 201836
should not be marked nounwind.
Marking them nounwind caused crashes in the WebKit FTL JIT, because if we enable
sufficient optimizations, LLVM starts eliding compact_unwind sections (or any unwind
data for that matter), making deoptimization via stackmaps impossible.
This changes the stackmap intrinsic to be may-throw, adds a test for exactly the
sympton that WebKit saw, and fixes TableGen to handle un-attributed intrinsics.
Thanks to atrick and philipreames for reviewing this.
llvm-svn: 201826
The SuppressWarnings flag, unfortunately, isn't very useful for custom tools
that want to use the LLVM module linker. So I'm changing it to a parameter of
the Linker, and the flag itself moves to the llvm-link tool.
For the time being as SuppressWarnings is pretty much the only "option" it
seems reasonable to propagate it to Linker objects. If we end up with more
options in the future, some sort of "struct collecting options" may be a
better idea.
llvm-svn: 201819
Change parameter names exposed in headers to avoid collisions with Objective-C++
keywords.
Contributed-by: Graham Lee <graham@iamleeg.com>
llvm-svn: 201727
TargetLoweringBase is implemented in CodeGen, so before this patch we had
a dependency fom Target to CodeGen. This would show up as a link failure of
llvm-stress when building with -DBUILD_SHARED_LIBS=ON.
This fixes pr18900.
llvm-svn: 201711
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
The same code (~20 lines) for initializing a TargetOptions object from CodeGen
cmdline flags is duplicated 4 times in 4 different tools. This patch moves it
into a utility function.
Since the CodeGen/CommandFlags.h file defines cl::opt flags in a header, it's
a bit of a touchy situation because we should only link them into tools. So this
patch puts the init function in the header.
llvm-svn: 201699
According to http://gcc.gnu.org/projects/cxx0x.html,
override and final keyword was added in gcc 4.7. Thus,
we should not use these keywords in gcc 4.6 even when
__GXX_EXPERIMENTAL_CXX0X__ is available.
llvm-svn: 201679
On x86, shifting a vector by a scalar is significantly cheaper than shifting a
vector by another fully general vector. Unfortunately, because SelectionDAG
operates on just one basic block at a time, the shufflevector instruction that
reveals whether the right-hand side of a shift *is* really a scalar is often
not visible to CodeGen when it's needed.
This adds another handler to CodeGenPrepare, to sink any useful shufflevector
instructions down to the basic block where they're used, predicated on a target
hook (since on other architectures, doing so will often just introduce extra
real work).
rdar://problem/16063505
llvm-svn: 201655
Load Configuration Table may contain a pointer to SEH table. This patch is to
print the offset to the table. Printing SEH table contents is a TODO.
The layout of Layout Configuration Table is described in Microsoft PE/COFF
Object File Format Spec, but the table's offset/size descriptions seems to be
totally wrong, at least in revision 8.3 of the spec. I believe the table in
this patch is the correct one.
llvm-svn: 201638
When outputting an object we check its section to find its name, but when
looking for the section with -ffunction-section we look for the symbol name.
Break the loop by requesting a name with the private prefix when constructing
the section name. This matches the behavior before r201608.
llvm-svn: 201622
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
During LSR of one loop we can run into a situation where we have to expand the
start of a recurrence of a loop induction variable in this loop. This start
value is a value derived of the induction variable of a preceeding loop. SCEV
has cannonicalized this value to a different recurrence than the recurrence of
the preceeding loop's induction variable (the type and/or step direction) has
changed). When we come to instantiate this SCEV we created a second induction
variable in this preceeding loop. This patch tries to base such derived
induction variables of the preceeding loop's induction variable.
This helps twolf on arm and seems to help scimark2 on x86.
Reapply with a fix for the case of a value derived from a pointer.
radar://15970709
llvm-svn: 201496
Adrian Prantl