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
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
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
// FIXME: We should compute this sooner, we don't want to recurse here, and
// we would like to be more functional.
In MCAssembler::ComputeFragmentSize.
llvm-svn: 118080
resolved or not. Different object files have different restrictions and
different native assemblers have different idiosyncrasies we want to emulate
for now.
Move the existing MachO logic to the new place and implement an ELF one that
gets fixups to globals right.
llvm-svn: 115131
Introduce a helper method to add a section to the end of a layout. This
will be used by the ELF ObjectWriter code to add the metadata sections
(symbol table, etc) to the end of an object file.
llvm-svn: 111171
- This eliminates getAtomForAddress() (which was a linear search) and
simplifies getAtom().
- This also fixes some correctness problems where local labels at the same
address as non-local labels could be assigned to the wrong atom.
llvm-svn: 103480
- 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.
llvm-svn: 99543
