| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
exactly two passes in that case, and don't ever need to recompute any layout,
so this is a nice baseline for relaxation performance.
llvm-svn: 99563
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
| |
llvm-svn: 99529
|
| |
|
|
| |
llvm-svn: 99528
|
| |
|
|
| |
llvm-svn: 99504
|
| |
|
|
| |
llvm-svn: 99500
|
| |
|
|
| |
llvm-svn: 99499
|
| |
|
|
| |
llvm-svn: 99474
|
| |
|
|
| |
llvm-svn: 99473
|
| |
|
|
| |
llvm-svn: 99467
|
| |
|
|
|
|
|
|
| |
address with a symbol address.
- This fixes the integrated-as nightly test regressions.
llvm-svn: 99466
|
| |
|
|
|
|
| |
MCAsmLayout object.
llvm-svn: 99380
|
| |
|
|
| |
llvm-svn: 99350
|
| |
|
|
| |
llvm-svn: 99348
|
| |
|
|
|
|
| |
Also, both MCMachOStreamer and MCAssembler are now target independent!
llvm-svn: 99256
|
| |
|
|
|
|
| |
particular instruction + fixups might need relaxation.
llvm-svn: 99249
|
| |
|
|
|
|
| |
dependencies in MCMachOStreamer and MCAssembler.
llvm-svn: 99248
|
| |
|
|
|
|
| |
don't need to recompute them during relaxation. I will revisit this once all the other pieces of fast relaxation are in place.
llvm-svn: 99244
|
| |
|
|
| |
llvm-svn: 99231
|
| |
|
|
| |
llvm-svn: 99229
|
| |
|
|
| |
llvm-svn: 99228
|
| |
|
|
|
|
| |
would do, and sprinkle in some const.
llvm-svn: 99218
|
| |
|
|
| |
llvm-svn: 99217
|
| |
|
|
| |
llvm-svn: 99216
|
| |
|
|
|
|
| |
of a MCDataFragment). Object files should only need the generic MCFragment features.
llvm-svn: 99205
|
| |
|
|
| |
llvm-svn: 99204
|
| |
|
|
| |
llvm-svn: 99203
|
| |
|
|
|
|
| |
important.
llvm-svn: 99202
|
| |
|
|
| |
llvm-svn: 99031
|
| |
|
|
| |
llvm-svn: 98994
|
| |
|
|
|
|
|
|
| |
- This is "extraordinarily" Darwin 'as' compatible. See the litany of FIXMEs littered about for more information.
- There are a few cases which seem to clearly be 'as' bugs which I have left unsupported, and there is one cases where we diverge but should fix if it blocks diffing .o files (Darwin 'as' ends up widening a jump unnecessarily).
- 403.gcc build, runs, and diffs equivalently to the 'as' built version now (using llvm-mc). However, it builds so slowly that I wouldn't recommend trying it quite yet. :)
llvm-svn: 98974
|
| |
|
|
|
|
| |
- MCAssembler is now object-file independent, although we will surely need more work to fully support ELF/COFF.
llvm-svn: 98955
|
| |
|
|
| |
llvm-svn: 98954
|
| |
|
|
| |
llvm-svn: 98953
|
| |
|
|
| |
llvm-svn: 98952
|
| |
|
|
| |
llvm-svn: 98950
|
| |
|
|
| |
llvm-svn: 98949
|
| |
|
|
| |
llvm-svn: 98948
|
| |
|
|
|
|
| |
specific not object writer specific task.
llvm-svn: 98947
|
| |
|
|
|
|
| |
and eliminate MCAsmFixup::FixedValue.
llvm-svn: 98944
|
| |
|
|
|
|
| |
changes the object writer may need to make to the assembler from the actual .o writing.
llvm-svn: 98943
|
| |
|
|
|
|
| |
evaluation / relocation handling from the actual .o writing.
llvm-svn: 98942
|
| |
|
|
|
|
| |
createAsmStreamer now takes ownership of the instprinter.
llvm-svn: 98939
|
| |
|
|
|
|
|
|
| |
algorithm (used on x86_64) for determining whether an evaluated fixup is fully resolved (doesn't need relocation).
- Test cases will follow, once we have x86_64 relocation support.
llvm-svn: 98926
|
| |
|
|
|
|
| |
- These find the defining symbol which identifies the containing atom for a symbol or address. They are currently very slow, but will be eliminated eventually.
llvm-svn: 98925
|
| |
|
|
|
|
| |
some corner cases.
llvm-svn: 98924
|
| |
|
|
|
|
| |
made up term to refer to non-temporary labels + temporary labels in sections-which-require symbols. For Darwin, it corresponds to symbols which effectively define an atom.
llvm-svn: 98923
|
| |
|
|
|
|
| |
need this for accessing to symbol modifiers.
llvm-svn: 98791
|
| |
|
|
|
|
|
|
| |
symbol differences, basically whether the assembler should attempt to understand atoms when using scattered symbols.
Also, avoid some virtual call overhead.
llvm-svn: 98789
|
| |
|
|
|
|
|
| |
should use CreateTempSymbol() if they don't care about the
name.
llvm-svn: 98712
|