| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 153429
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We on the linker to resolve calls to the appropriate BL/BLX instruction
to make interworking function correctly. It uses the symbol in the
relocation to do that, so we need to be careful about being too clever.
To enable this for ARM mode, split the BL/BLX fixup kind off from the
unconditional-branch fixups.
rdar://10927209
llvm-svn: 151571
|
|
|
|
| |
llvm-svn: 149967
|
|
|
|
| |
llvm-svn: 149105
|
|
|
|
| |
llvm-svn: 148400
|
|
|
|
| |
llvm-svn: 148364
|
|
|
|
|
|
| |
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146960
|
|
|
|
|
|
|
|
| |
Whether a fixup needs relaxation for the associated instruction is a
target-specific function, as the FIXME indicated. Create a hook for that
and use it.
llvm-svn: 145881
|
|
|
|
| |
llvm-svn: 145878
|
|
|
|
|
|
| |
per http://llvm.org/docs/CodingStandards.html#ll_naming
llvm-svn: 145873
|
|
|
|
|
|
| |
Replaces r145318 with a more targetted fix for the relocation handling.
llvm-svn: 145346
|
|
|
|
|
|
| |
rdar://10493453
llvm-svn: 145318
|
|
|
|
| |
llvm-svn: 143071
|
|
|
|
|
|
| |
These are strictly utilities for registering targets and components.
llvm-svn: 138450
|
|
|
|
|
|
| |
createMCAsmBackend.
llvm-svn: 136010
|
|
|
|
|
|
| |
they belong.
llvm-svn: 135833
|
|
|
|
|
|
|
| |
the smaller encoding and this cuts 270336 bytes from a release version of
clang and 1246272 bytes from a debug build.
llvm-svn: 131067
|
|
|
|
|
|
| |
currently used, because variables don't get reported as being "defined".
llvm-svn: 130524
|
|
|
|
|
|
|
| |
This removes one of the main advantages of moving eh_frame to MC, but
makes the transition a lot easier to debug (run md5).
llvm-svn: 130379
|
|
|
|
| |
llvm-svn: 130181
|
|
|
|
| |
llvm-svn: 130068
|
|
|
|
|
|
| |
the right thing and stop trying to copy it. Fixes PR8944.
llvm-svn: 125648
|
|
|
|
| |
llvm-svn: 124077
|
|
|
|
| |
llvm-svn: 122591
|
|
|
|
|
|
| |
have a single point where targets test if a relocation is needed.
llvm-svn: 122549
|
|
|
|
|
|
| |
if we have a lame assembler.
llvm-svn: 122446
|
|
|
|
| |
llvm-svn: 122405
|
|
|
|
|
|
|
| |
are not actually relaxed. For example, a section with only alignments will never
needs relaxation.
llvm-svn: 122356
|
|
|
|
|
|
|
|
|
|
| |
section.
This helps because in practice sections form a dag with debug sections pointing
to text sections. Finishing up the text sections first makes the debug section
relaxation trivial.
llvm-svn: 122314
|
|
|
|
|
|
|
|
|
| |
not just to the fragment relative
portion. While the fragment boundary is usually already aligned, it is possible for it not to be, which
would lead to a non-aligned final displacement.
llvm-svn: 122091
|
|
|
|
|
|
| |
-- and remove FIXME asking for the same!
llvm-svn: 122032
|
|
|
|
|
|
| |
assembler.
llvm-svn: 122031
|
|
|
|
|
|
|
| |
the MCCodeEmitter, which seems like a better organization.
- Also, cleaned up some magic constants while in the area.
llvm-svn: 121953
|
|
|
|
| |
llvm-svn: 121880
|
|
|
|
| |
llvm-svn: 121875
|
|
|
|
|
|
|
|
|
|
|
| |
With this we don't need the EffectiveSize field anymore. Without that field
LayoutFragment only updates offsets and we don't need to invalidate the
current fragment when it is relaxed (only the ones following it).
This is also a very small improvement in the accuracy of the layout info as
we now use the after relaxation size immediately.
llvm-svn: 121857
|
|
|
|
|
|
|
| |
Since we now don't update addresses so early, we might relax a bit more than
we need to. This is simillar to the issue in PR8467.
llvm-svn: 121856
|
|
|
|
|
|
| |
set for interworking to work properly. rdar://8755956
llvm-svn: 121778
|
|
|
|
|
|
|
|
|
|
| |
be 4-byte aligned when calculating
the offset. Add a new fixup flag to represent this, and use it for the one fixups that I have a testcase for needing
this. It's quite likely that the other Thumb fixups will need this too, and to have their fixup encoding logic
adjusted accordingly.
llvm-svn: 121408
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
before:
4 assembler - Number of assembler layout and relaxation steps
78563 assembler - Number of emitted assembler fragments
8693904 assembler - Number of emitted object file bytes
271223 assembler - Number of evaluated fixups
330771677 assembler - Number of fragment layouts
5958 assembler - Number of relaxed instructions
2508361 mcexpr - Number of MCExpr evaluations
real 0m26.123s
user 0m25.694s
sys 0m0.388s
after:
4 assembler - Number of assembler layout and relaxation steps
78563 assembler - Number of emitted assembler fragments
8693904 assembler - Number of emitted object file bytes
271223 assembler - Number of evaluated fixups
231507 assembler - Number of fragment layouts
5958 assembler - Number of relaxed instructions
2508361 mcexpr - Number of MCExpr evaluations
real 0m2.500s
user 0m2.113s
sys 0m0.273s
And yes, the outputs are identical :-)
llvm-svn: 121207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
actuall addresses in a .o file, so it is better to let the MachO writer compute
it.
This is good for two reasons. First, areas that shouldn't care about
addresses now don't have access to it. Second, the layout of each section
is independent. I should use this in a subsequent commit to speed it up.
Most of the patch is just removing the section address computation. The two
interesting parts are the change on how we handle padding in the end
of sections and how MachO can get the address of a-b when a and b are in
different sections.
Since now the expression evaluation normally doesn't know the section address,
it will think that a-b needs relocation and let the MachO writer know. Once
it has computed the section addresses, it calls back the expression evaluation
with the section addresses to resolve these expressions.
The remaining problem is the handling of padding. Currently it will create
a special alignment fragment at the end. Since that fragment doesn't update
the alignment of the section, it needs the real address to be computed.
Since now the layout will not compute a-b with a and b in different sections,
the only effect that the special alignment fragment has is update the
address size of the section. This can also be done by the MachO writer.
llvm-svn: 121076
|
|
|
|
| |
llvm-svn: 121050
|
|
|
|
|
|
| |
freed data to be read. I will open a bug to track it being reenabled.
llvm-svn: 121028
|
|
|
|
|
|
| |
that on the ELF writer to detect a section we created.
llvm-svn: 120981
|
|
|
|
| |
llvm-svn: 120977
|
|
|
|
|
|
| |
valid. Addresses will not change.
llvm-svn: 120921
|
|
|
|
|
|
| |
having to evaluate the expression again when writing.
llvm-svn: 120920
|
|
|
|
|
|
|
|
| |
contain only data. Handle them specially instead of using AddSectionToTheEnd.
This moves a hack from the generic assembler to the elf writer. It is also
a bit faster and should make other improvements easier.
llvm-svn: 120683
|
|
|
|
| |
llvm-svn: 120621
|
|
|
|
|
|
|
|
| |
David Meyer.
While here, remove unused argument and rename UpdateForSlide to Invalidate.
llvm-svn: 120009
|