| .. |
|
aoptcpu.pas
|
2fa066b003
* optimize vmovaps/vmovapd after avx instructions
|
%!s(int64=11) %!d(string=hai) anos |
|
aoptcpub.pas
|
2f5ce095ce
* RefsHaveIndexReg -> cpurefshaveindexreg
|
%!s(int64=13) %!d(string=hai) anos |
|
aoptcpud.pas
|
790a4fe2d3
* log and id tags removed
|
%!s(int64=20) %!d(string=hai) anos |
|
cgcpu.pas
|
35a04ad095
* modified patch of Paul W to replace leave by mov/pop, resolves #26455
|
%!s(int64=10) %!d(string=hai) anos |
|
cpubase.inc
|
bfbb0c5b9d
* optimize mov/lea
|
%!s(int64=12) %!d(string=hai) anos |
|
cpuelf.pas
|
c7e939b243
Add x86_64-solaris to the list of supported targetss for as_x86_64_elf64 binary writer
|
%!s(int64=10) %!d(string=hai) anos |
|
cpuinfo.pas
|
5c67fcc43f
+ change always floating point divisions into multiplications if they are a power of two,
|
%!s(int64=10) %!d(string=hai) anos |
|
cpunode.pas
|
b57c95043f
+ support overriding tdef/tsym methods with target-specific functionality:
|
%!s(int64=11) %!d(string=hai) anos |
|
cpupara.pas
|
d8c898742a
* handle the fact that records containing a single extended value are
|
%!s(int64=10) %!d(string=hai) anos |
|
cpupi.pas
|
70dda94474
* x86_64-win64: don't allocate outgoing parameter area in nostackframe procedures, it fails compilation if range/overflow/etc checking is enabled (which always sets pi_do_call) due to check introduced in r22677.
|
%!s(int64=12) %!d(string=hai) anos |
|
cputarg.pas
|
3327d508ee
Enable nasm assembler for x86_64 cpu
|
%!s(int64=11) %!d(string=hai) anos |
|
hlcgcpu.pas
|
71deda6f50
+ added interface to ncgutil.gen_load_loc_cgpara() to hlcgobj + generic
|
%!s(int64=14) %!d(string=hai) anos |
|
nx64add.pas
|
2459518bdd
* use IMUL even for unsigned multiplication on x86_64, when overflow checking is
|
%!s(int64=11) %!d(string=hai) anos |
|
nx64cal.pas
|
b837694207
* factored out releasing an unused return value into
|
%!s(int64=14) %!d(string=hai) anos |
|
nx64cnv.pas
|
edd42aa42a
* moved subsetref/reg and bit_set/test support from cgobj to hlcgobj for
|
%!s(int64=13) %!d(string=hai) anos |
|
nx64flw.pas
|
ed4e876f4f
* Generate exception filters data on i386-win32 and x86_64-win64 without using global labels.
|
%!s(int64=10) %!d(string=hai) anos |
|
nx64inl.pas
|
790a4fe2d3
* log and id tags removed
|
%!s(int64=20) %!d(string=hai) anos |
|
nx64mat.pas
|
b594eee70b
* Moved x86_64 mod/div code to x86, with minimal changes to ensure it compiles on i386/i8086. Merging optimized division-by-const code from i386 is pending...
|
%!s(int64=11) %!d(string=hai) anos |
|
nx64set.pas
|
859676d7d3
* fixed r26519 for darwin/x86-64, see comments (mantis #25644)
|
%!s(int64=11) %!d(string=hai) anos |
|
r8664ari.inc
|
5af873ee5b
* x86 targets: Profiling shows that quite a bit of time is spent in findreg_by_number(), despite it uses binary search. Worse, it is repeated for every piece of register information. Trying to get rid of some of these calls: rearranged registers so that their "opcode" matches 3 LSBs of superregister number (with a few exceptions described at the beginning of x86reg.dat). This allows to lookup opcodes in regval() with O(1) complexity, and removes need in rXXXop.inc files.
|
%!s(int64=12) %!d(string=hai) anos |
|
r8664att.inc
|
5af873ee5b
* x86 targets: Profiling shows that quite a bit of time is spent in findreg_by_number(), despite it uses binary search. Worse, it is repeated for every piece of register information. Trying to get rid of some of these calls: rearranged registers so that their "opcode" matches 3 LSBs of superregister number (with a few exceptions described at the beginning of x86reg.dat). This allows to lookup opcodes in regval() with O(1) complexity, and removes need in rXXXop.inc files.
|
%!s(int64=12) %!d(string=hai) anos |
|
r8664con.inc
|
5af873ee5b
* x86 targets: Profiling shows that quite a bit of time is spent in findreg_by_number(), despite it uses binary search. Worse, it is repeated for every piece of register information. Trying to get rid of some of these calls: rearranged registers so that their "opcode" matches 3 LSBs of superregister number (with a few exceptions described at the beginning of x86reg.dat). This allows to lookup opcodes in regval() with O(1) complexity, and removes need in rXXXop.inc files.
|
%!s(int64=12) %!d(string=hai) anos |
|
r8664dwrf.inc
|
5af873ee5b
* x86 targets: Profiling shows that quite a bit of time is spent in findreg_by_number(), despite it uses binary search. Worse, it is repeated for every piece of register information. Trying to get rid of some of these calls: rearranged registers so that their "opcode" matches 3 LSBs of superregister number (with a few exceptions described at the beginning of x86reg.dat). This allows to lookup opcodes in regval() with O(1) complexity, and removes need in rXXXop.inc files.
|
%!s(int64=12) %!d(string=hai) anos |
|
r8664int.inc
|
5af873ee5b
* x86 targets: Profiling shows that quite a bit of time is spent in findreg_by_number(), despite it uses binary search. Worse, it is repeated for every piece of register information. Trying to get rid of some of these calls: rearranged registers so that their "opcode" matches 3 LSBs of superregister number (with a few exceptions described at the beginning of x86reg.dat). This allows to lookup opcodes in regval() with O(1) complexity, and removes need in rXXXop.inc files.
|
%!s(int64=12) %!d(string=hai) anos |
|
r8664iri.inc
|
5af873ee5b
* x86 targets: Profiling shows that quite a bit of time is spent in findreg_by_number(), despite it uses binary search. Worse, it is repeated for every piece of register information. Trying to get rid of some of these calls: rearranged registers so that their "opcode" matches 3 LSBs of superregister number (with a few exceptions described at the beginning of x86reg.dat). This allows to lookup opcodes in regval() with O(1) complexity, and removes need in rXXXop.inc files.
|
%!s(int64=12) %!d(string=hai) anos |
|
r8664nasm.inc
|
2ec5a649d7
* set Ch_* for more operations
|
%!s(int64=11) %!d(string=hai) anos |
|
r8664nor.inc
|
283ff05127
* merged avx support in inline assembler developed by Torsten Grundke
|
%!s(int64=13) %!d(string=hai) anos |
|
r8664num.inc
|
5af873ee5b
* x86 targets: Profiling shows that quite a bit of time is spent in findreg_by_number(), despite it uses binary search. Worse, it is repeated for every piece of register information. Trying to get rid of some of these calls: rearranged registers so that their "opcode" matches 3 LSBs of superregister number (with a few exceptions described at the beginning of x86reg.dat). This allows to lookup opcodes in regval() with O(1) complexity, and removes need in rXXXop.inc files.
|
%!s(int64=12) %!d(string=hai) anos |
|
r8664ot.inc
|
5af873ee5b
* x86 targets: Profiling shows that quite a bit of time is spent in findreg_by_number(), despite it uses binary search. Worse, it is repeated for every piece of register information. Trying to get rid of some of these calls: rearranged registers so that their "opcode" matches 3 LSBs of superregister number (with a few exceptions described at the beginning of x86reg.dat). This allows to lookup opcodes in regval() with O(1) complexity, and removes need in rXXXop.inc files.
|
%!s(int64=12) %!d(string=hai) anos |
|
r8664rni.inc
|
5af873ee5b
* x86 targets: Profiling shows that quite a bit of time is spent in findreg_by_number(), despite it uses binary search. Worse, it is repeated for every piece of register information. Trying to get rid of some of these calls: rearranged registers so that their "opcode" matches 3 LSBs of superregister number (with a few exceptions described at the beginning of x86reg.dat). This allows to lookup opcodes in regval() with O(1) complexity, and removes need in rXXXop.inc files.
|
%!s(int64=12) %!d(string=hai) anos |
|
r8664sri.inc
|
5af873ee5b
* x86 targets: Profiling shows that quite a bit of time is spent in findreg_by_number(), despite it uses binary search. Worse, it is repeated for every piece of register information. Trying to get rid of some of these calls: rearranged registers so that their "opcode" matches 3 LSBs of superregister number (with a few exceptions described at the beginning of x86reg.dat). This allows to lookup opcodes in regval() with O(1) complexity, and removes need in rXXXop.inc files.
|
%!s(int64=12) %!d(string=hai) anos |
|
r8664stab.inc
|
5af873ee5b
* x86 targets: Profiling shows that quite a bit of time is spent in findreg_by_number(), despite it uses binary search. Worse, it is repeated for every piece of register information. Trying to get rid of some of these calls: rearranged registers so that their "opcode" matches 3 LSBs of superregister number (with a few exceptions described at the beginning of x86reg.dat). This allows to lookup opcodes in regval() with O(1) complexity, and removes need in rXXXop.inc files.
|
%!s(int64=12) %!d(string=hai) anos |
|
r8664std.inc
|
5af873ee5b
* x86 targets: Profiling shows that quite a bit of time is spent in findreg_by_number(), despite it uses binary search. Worse, it is repeated for every piece of register information. Trying to get rid of some of these calls: rearranged registers so that their "opcode" matches 3 LSBs of superregister number (with a few exceptions described at the beginning of x86reg.dat). This allows to lookup opcodes in regval() with O(1) complexity, and removes need in rXXXop.inc files.
|
%!s(int64=12) %!d(string=hai) anos |
|
rax64att.pas
|
8f05f8c839
- Forgot to commit with r29081
|
%!s(int64=10) %!d(string=hai) anos |
|
rax64int.pas
|
f726e1691b
* Fixed warnings and notes.
|
%!s(int64=16) %!d(string=hai) anos |
|
rgcpu.pas
|
a3f58e84be
* rbp can be used for normal purpose under certain conditions so it shouldn't interfere with all other registers
|
%!s(int64=11) %!d(string=hai) anos |
|
symcpu.pas
|
94bcb9878a
* reimplemented r28329 in a different way, as suggested by Jonas
|
%!s(int64=11) %!d(string=hai) anos |
|
win64unw.pas
|
6a3fe72de9
+ Support .rva directive in AT&T reader. Put it into base class because it generally applies to all targets with COFF output, but enabled for Windows targets only (others need additional testing).
|
%!s(int64=14) %!d(string=hai) anos |
|
x8664ats.inc
|
dc628b8969
* x86: Completely skip instructions that do not exist for target CPU bit width. The existing behavior of writing mnemonics and properties but no encoding allows an invalid instruction to be recognized by assembler reader or even generated by compiler, but it but won't assemble anyway.
|
%!s(int64=11) %!d(string=hai) anos |
|
x8664att.inc
|
dc628b8969
* x86: Completely skip instructions that do not exist for target CPU bit width. The existing behavior of writing mnemonics and properties but no encoding allows an invalid instruction to be recognized by assembler reader or even generated by compiler, but it but won't assemble anyway.
|
%!s(int64=11) %!d(string=hai) anos |
|
x8664int.inc
|
dc628b8969
* x86: Completely skip instructions that do not exist for target CPU bit width. The existing behavior of writing mnemonics and properties but no encoding allows an invalid instruction to be recognized by assembler reader or even generated by compiler, but it but won't assemble anyway.
|
%!s(int64=11) %!d(string=hai) anos |
|
x8664nop.inc
|
842e027a9f
+ prove of concept how FMA4 could be supported in inline assembler
|
%!s(int64=11) %!d(string=hai) anos |
|
x8664op.inc
|
dc628b8969
* x86: Completely skip instructions that do not exist for target CPU bit width. The existing behavior of writing mnemonics and properties but no encoding allows an invalid instruction to be recognized by assembler reader or even generated by compiler, but it but won't assemble anyway.
|
%!s(int64=11) %!d(string=hai) anos |
|
x8664pro.inc
|
dc628b8969
* x86: Completely skip instructions that do not exist for target CPU bit width. The existing behavior of writing mnemonics and properties but no encoding allows an invalid instruction to be recognized by assembler reader or even generated by compiler, but it but won't assemble anyway.
|
%!s(int64=11) %!d(string=hai) anos |
|
x8664tab.inc
|
842e027a9f
+ prove of concept how FMA4 could be supported in inline assembler
|
%!s(int64=11) %!d(string=hai) anos |
florian
35a04ad095
* modified patch of Paul W to replace leave by mov/pop, resolves #26455