| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
I will use it there in a second.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207761 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
This simplifies ELFObjectWriter::SymbolValue a bit more. This new version
will also be used in the COFF writer to fix pr19147.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207711 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when a fragment is relaxed, its size is modified, but its
offset is not (it gets laid out as a side effect of checking whether
it needs relaxation), then all subsequent fragments are invalidated
because their offsets need to change. When bundling is enabled,
relaxed fragments need to get laid out again, because the increase in
size may push it over a bundle boundary. So instead of only
invalidating subsequent fragments, also invalidate the fragment that
gets relaxed, which causes it to get laid out again.
This patch also fixes some trailing whitespace and fixes the
bundling-related debug output of MCFragments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174401 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056754.html
The proposal and implementation are fully documented here:
https://sites.google.com/a/chromium.org/dev/nativeclient/pnacl/aligned-bundling-support-in-llvm
Tests will follow shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170718 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170007 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169762 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144537 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
Luis Felipe Strano Moraes!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129558 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122010 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121857 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121207 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121076 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
freed data to be read. I will open a bug to track it being reenabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121028 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120977 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
David Meyer.
While here, remove unused argument and rename UpdateForSlide to Invalidate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120009 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119999 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
- The eliminates the last major algorithmic problem with MC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103754 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
out, and enforce several invariants to LayoutFragment to ensure we only do layout in a sensible order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103753 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Also, elimminate MCAsmLayout::set*, which are no longer needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103750 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103738 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103709 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
utility functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103695 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
consumed by the section. This can differ from both the section logical size, and the section size on disk (although the current code handles this without making an explicit distinction).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103689 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103627 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103616 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Still O(N^2), just a faster form, and now its the MCAsmLayout's fault.
On the .s I am tuning against (combine.s from 403.gcc):
--
ddunbar@lordcrumb:MC$ diff stats-before.txt stats-after.txt
5,10c5,10
< 1728 assembler - Number of assembler layout and relaxation steps
< 7707 assembler - Number of emitted assembler fragments
< 120588 assembler - Number of emitted object file bytes
< 2233448 assembler - Number of evaluated fixups
< 1727 assembler - Number of relaxed instructions
< 6723845 mcexpr - Number of MCExpr evaluations
---
> 3 assembler - Number of assembler layout and relaxation steps
> 7707 assembler - Number of emitted assembler fragments
> 120588 assembler - Number of emitted object file bytes
> 14796 assembler - Number of evaluated fixups
> 1727 assembler - Number of relaxed instructions
> 67889 mcexpr - Number of MCExpr evaluations
--
Feel free to LOL at the -before numbers, if you like.
I am a little surprised we make more than 2 relaxation passes. It's pretty
trivial for us to do relaxation out-of-order if that would give a speedup.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99543 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99474 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99473 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
MCAsmLayout object.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99380 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98380 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
- Also, drop the current location part of AsmLayout, I think I prefer to implement this via explicit symbols.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98240 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of an assembly file. The MCAsmLayout is also available for use by MCExpr::EvaluateAs{Absolute,Relocatable}, to allow target specific hooks and "absolutizing" of symbols.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98227 91177308-0d34-0410-b5e6-96231b3b80d8
|