| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 191927
|
|
|
|
|
|
|
|
|
|
| |
The size of common symbols is now tracked correctly, so they can be listed in the arange section without needing knowledge of other following symbols.
.comm (and .lcomm) do not indicate to the system assembler any particular section to use, so we have to treat them as having no section.
Test case update to account for this.
llvm-svn: 191210
|
|
|
|
| |
llvm-svn: 191052
|
|
|
|
|
|
|
|
|
| |
Previous discussion:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html
Differential Revision: http://llvm-reviews.chandlerc.com/D1191
llvm-svn: 190773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'Deprecated' class allows you to specify a SubtargetFeature that the
instruction is deprecated on.
The 'ComplexDeprecationPredicate' class allows you to define a custom
predicate that is called to check for deprecation.
For example:
ComplexDeprecationPredicate<"MCR">
would mean you would have to define the following function:
bool getMCRDeprecationInfo(MCInst &MI, MCSubtargetInfo &STI,
std::string &Info)
Which returns 'false' for not deprecated, and 'true' for deprecated
and store the warning message in 'Info'.
The MCTargetAsmParser constructor was chaned to take an extra argument of
the MCInstrInfo class, so out-of-tree targets will need to be changed.
llvm-svn: 190598
|
|
|
|
|
|
|
|
|
| |
We currently emit labels with the prefix Lllvm$workaround$fake$stub$ if
the target's MCAsmInfo has getLinkOnceDirective() mapped to something
interesting. This was apparently a work around introduced in r31033 for
binutils that we don't need anymore.
llvm-svn: 189187
|
|
|
|
|
|
| |
Replace instances of this scattered around the code base.
llvm-svn: 189169
|
|
|
|
| |
llvm-svn: 188484
|
|
|
|
| |
llvm-svn: 188483
|
|
|
|
|
|
| |
relative item only when it's one of dw_from strp, sec_offset, ref_addr or op_call_ref instead of going by size.
llvm-svn: 188296
|
|
|
|
|
|
|
|
|
| |
.tbss section for zerofill thread locals. Make sure we do this
before emitting the zerofills.
Fixes PR15972.
llvm-svn: 187913
|
|
|
|
|
|
| |
secrel32 instead of long opcodes (only for coff). This makes them debuggable with GDB (with fix for 64bits msvc)
llvm-svn: 187656
|
|
|
|
|
|
|
|
| |
code emitted as secrel32 instead of long opcodes (only for coff). This makes them debuggable with GDB."
It broke x86_64-win32 builder in llvm/test/DebugInfo.
llvm-svn: 187642
|
|
|
|
|
|
|
|
| |
secrel32 instead of long opcodes (only for coff). This makes them debuggable with GDB.
fixes Bug 16249 - LLVM generates broken debug info on Windows
llvm-svn: 187597
|
|
|
|
| |
llvm-svn: 186371
|
|
|
|
|
|
|
|
|
|
|
| |
MF is normally initialized in AsmPrinter::SetupMachineFunction, but if the file
contains only globals (no functions), then we need this to be initialized
because, when encountering an error, lowerConstant() references it.
This should fix the non-deterministic failures of
test/CodeGen/X86/nonconst-static-iv.ll, etc.
llvm-svn: 186068
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the informal convention of DBG_VALUE machine instructions so that
we can express a register-indirect address with an offset of 0.
The old convention was that a DBG_VALUE is a register-indirect value if
the offset (operand 1) is nonzero. The new convention is that a DBG_VALUE
is register-indirect if the first operand is a register and the second
operand is an immediate. For plain register values the combination reg,
reg is used. MachineInstrBuilder::BuildMI knows how to build the new
DBG_VALUES.
rdar://problem/13658587
llvm-svn: 185966
|
|
|
|
|
|
|
|
|
| |
r179494 switched to using the object file info to retrieve the default text
section for some MC streamers. It is possible that initializing an MC
streamer can request sections before the object file info is initialized
when the AutoInitSections flag is set on the streamer.
llvm-svn: 185670
|
|
|
|
|
|
|
|
| |
This is dead code since PIC16 was removed in 2010. The result was an odd mix,
where some parts would carefully pass it along and others would assert it was
zero (most of the object streamer for example).
llvm-svn: 185436
|
|
|
|
| |
llvm-svn: 184792
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had been papering over a problem with location info for non-trivial
types passed by value by emitting their type as references (this caused
the debugger to interpret the location information correctly, but broke
the type of the function). r183329 corrected the type information but
lead to the debugger interpreting the pointer parameter as the value -
the debug info describing the location needed an extra dereference.
Use a new flag in DIVariable to add the extra indirection (either by
promoting an existing DW_OP_reg (parameter passed in a register) to
DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n
(parameter passed on the stack).
llvm-svn: 184368
|
|
|
|
|
|
|
|
|
|
| |
MachineInstrs
Frame index handling is now target-agnostic, so delete the target hooks
for creation & asm printing of target-specific addressing in DBG_VALUEs
and any related functions.
llvm-svn: 184067
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than using the full power of target-specific addressing modes in
DBG_VALUEs with Frame Indicies, simply use Frame Index + Offset. This
reduces the complexity of debug info handling down to two
representations of values (reg+offset and frame index+offset) rather
than three or four.
Ideally we could ensure that frame indicies had been eliminated by the
time we reached an assembly or dwarf generation, but I haven't spent the
time to figure out where the FIs are leaking through into that & whether
there's a good place to convert them. Some FI+offset=>reg+offset
conversion is done (see PrologEpilogInserter, for example) which is
necessary for some SelectionDAG assumptions about registers, I believe,
but it might be possible to make this a more thorough conversion &
ensure there are no remaining FIs no matter how instruction selection
is performed.
llvm-svn: 184066
|
|
|
|
|
|
| |
offset when it's zero
llvm-svn: 184045
|
|
|
|
|
|
| |
comments if the display name is empty
llvm-svn: 184026
|
|
|
|
|
|
|
|
|
|
|
| |
Fix an assertion when the compiler encounters big constants whose bit width is
not a multiple of 64-bits.
Although clang would never generate something like this, the backend should be
able to handle any legal IR.
<rdar://problem/13363576>
llvm-svn: 183544
|
|
|
|
|
|
| |
Not only does this break encapsulation, it's gross.
llvm-svn: 182876
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was just a less powerful and more confusing version of
MCCFIInstruction. A side effect is that, since MCCFIInstruction uses
dwarf register numbers, calls to getDwarfRegNum are pushed out, which
should allow further simplifications.
I left the MachineModuleInfo::addFrameMove interface unchanged since
this patch was already fairly big.
llvm-svn: 181680
|
|
|
|
|
|
|
| |
To add a frame now there is a dedicated addFrameMove which also takes
care of constructing the move itself.
llvm-svn: 181657
|
|
|
|
|
|
| |
right now.
llvm-svn: 180889
|
|
|
|
|
|
|
|
|
|
| |
can express a"
because it breaks some buildbots.
This reverts commit 180816.
llvm-svn: 180819
|
|
|
|
|
|
|
|
|
|
|
|
| |
register-indirect address with an offset of 0.
It used to be that a DBG_VALUE is a register-indirect value if the offset
(operand 1) is nonzero. The new convention is that a DBG_VALUE is
register-indirect if the first operand is a register and the second
operand is an immediate. For plain registers use the combination reg, reg.
rdar://problem/13658587
llvm-svn: 180816
|
|
|
|
|
|
|
|
|
|
| |
The `llvm.tls_init_funcs' (created by the front-end) holds pointers to the TLS
initialization functions. These need to be placed into the correct section so
that they are run before `main()'.
<rdar://problem/13733006>
llvm-svn: 180737
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to determine whether or not we're on a darwin platform for debug code
emitting.
Solves the problem of a module with no triple on the command line
and no triple in the module using non-gdb ok features on darwin. Fix
up the member-pointers test to check the correct things for cross
platform (DW_FORM_flag is a good prefix).
Unfortunately no testcase because I have no ideas how to test something
without a triple and without a triple in the module yet check
precisely on two platforms. Ideas welcome.
llvm-svn: 180660
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clarify documentation and API to make the difference between register and
register-indirect addressed locations more explicit. Put in a comment
to point out that with the current implementation we cannot specify
a register-indirect location with offset 0 (a breg 0 in DWARF).
No functionality change intended.
rdar://problem/13658587
llvm-svn: 180641
|
|
|
|
|
|
|
| |
Also add a check for llvm.used in the verifier and simplify clients now that
they can assume they have a ConstantArray.
llvm-svn: 180019
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D598
llvm-svn: 179725
|
|
|
|
|
|
|
| |
This removes previous special cases for each floating-point type in favour of a
shared codepath.
llvm-svn: 172189
|
|
|
|
|
|
| |
them.
llvm-svn: 171933
|
|
|
|
|
|
| |
them and add one where it seemed obvious that we wanted one.
llvm-svn: 171932
|
|
|
|
| |
llvm-svn: 171866
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
llvm-svn: 171366
|
|
|
|
|
|
|
|
|
| |
GEP::accumulateConstantOffset().
The later API is nicer than the former, and is correct regarding wrap-around offsets (if anyone cares).
There are a few more places left with duplicated code, which I'll remove soon.
llvm-svn: 171259
|
|
|
|
|
|
|
|
| |
the asm printer,
also changed MCContext to a single reset only method for simplicity as requested on the list
llvm-svn: 170041
|
|
|
|
|
|
|
|
| |
InitSections is called before the MCContext is initialized it could cause
duplicate temporary symbols to be emitted later (after context initialization
resets the temporary label counter).
llvm-svn: 169785
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
|
|
|
|
|
|
|
| |
argument. Instead, use a pair of .local and .comm directives.
This avoids spurious differences between binaries built by the
integrated assembler vs. those built by the external assembler,
since the external assembler may impose alignment requirements
on .lcomm symbols where the integrated assembler does not.
llvm-svn: 168704
|
|
|
|
| |
llvm-svn: 168383
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r165941: Resubmit the changes to llvm core to update the functions to
support different pointer sizes on a per address space basis.
Despite this commit log, this change primarily changed stuff outside of
VMCore, and those changes do not carry any tests for correctness (or
even plausibility), and we have consistently found questionable or flat
out incorrect cases in these changes. Most of them are probably correct,
but we need to devise a system that makes it more clear when we have
handled the address space concerns correctly, and ideally each pass that
gets updated would receive an accompanying test case that exercises that
pass specificaly w.r.t. alternate address spaces.
However, from this commit, I have retained the new C API entry points.
Those were an orthogonal change that probably should have been split
apart, but they seem entirely good.
In several places the changes were very obvious cleanups with no actual
multiple address space code added; these I have not reverted when
I spotted them.
In a few other places there were merge conflicts due to a cleaner
solution being implemented later, often not using address spaces at all.
In those cases, I've preserved the new code which isn't address space
dependent.
This is part of my ongoing effort to clean out the partial address space
code which carries high risk and low test coverage, and not likely to be
finished before the 3.2 release looms closer. Duncan and I would both
like to see the above issues addressed before we return to these
changes.
llvm-svn: 167222
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getIntPtrType support for multiple address spaces via a pointer type,
and also introduced a crasher bug in the constant folder reported in
PR14233.
These commits also contained several problems that should really be
addressed before they are re-committed. I have avoided reverting various
cleanups to the DataLayout APIs that are reasonable to have moving
forward in order to reduce the amount of churn, and minimize the number
of commits that were reverted. I've also manually updated merge
conflicts and manually arranged for the getIntPtrType function to stay
in DataLayout and to be defined in a plausible way after this revert.
Thanks to Duncan for working through this exact strategy with me, and
Nick Lewycky for tracking down the really annoying crasher this
triggered. (Test case to follow in its own commit.)
After discussing with Duncan extensively, and based on a note from
Micah, I'm going to continue to back out some more of the more
problematic patches in this series in order to ensure we go into the
LLVM 3.2 branch with a reasonable story here. I'll send a note to
llvmdev explaining what's going on and why.
Summary of reverted revisions:
r166634: Fix a compiler warning with an unused variable.
r166607: Add some cleanup to the DataLayout changes requested by
Chandler.
r166596: Revert "Back out r166591, not sure why this made it through
since I cancelled the command. Bleh, sorry about this!
r166591: Delete a directory that wasn't supposed to be checked in yet.
r166578: Add in support for getIntPtrType to get the pointer type based
on the address space.
llvm-svn: 167221
|