search for: x86instinfo

Can someone explain the Constraints system in X86*.td? For example: let Constraints = "$src1 = $dst" This replaces isTwoAddress (according to svn logs), which I gather is how two-address instructions used to be marked for X86. Except isTwoAddress is still used in X86InstInfo.td. So what gives? What do these two properties actually do? -Dave

..."$src1 = $dst" > > This replaces isTwoAddress (according to svn logs), which I gather > is how > two-address instructions used to be marked for X86. You're right. This is the same as isTwoAddress, just more flexible. > > > Except isTwoAddress is still used in X86InstInfo.td. Because I haven't replaced all uses of isTwoAddress with constraints, that's all. Evan > > > So what gives? What do these two properties actually do? > > -Dave > _______________________________________________ > LLVM D...

...or the rest of llvm? What does this constrait say to later phases? Is it a requirement that all two-address instructions have this constraint or does it just enable more optimization? That is, is functional correctness tied to using this constraint? > > Except isTwoAddress is still used in X86InstInfo.td. > > Because I haven't replaced all uses of isTwoAddress with constraints, > that's all. Gotcha. Thanks. -Dave

...e syntax follows Microsoft MASM requirements. The main problem that I have hit is regarding the use of CL register in the shift instructions. The problem is that ATT syntax states that it should be referenced as "%cl" while Intel says just "cl" but these references occur in X86InstInfo.td and this means that it is shared between Intel and ATT printing! For example, the shift rules: let Uses = [CL] in { def SHL8rCL : I<0xD2, MRM4r, (outs GR8 :$dst), (ins GR8 :$src), "shl{b}\t{%cl, $dst|$dst, %CL}", [(set GR8:$dst, (shl GR8:$sr...

...t. (The output of "svn diff" is fine.) > The main problem that I have hit is regarding the use of CL register in the > shift instructions. The problem is that ATT syntax states that it should be > referenced as “%cl” while Intel says just “cl” but these references occur in > X86InstInfo.td and this means that it is shared between Intel and ATT > printing! For example, the shift rules: We have two different output styles for precisely that reason. > The problem is that it does not make sense to have separate rules for Intel > and ATT and as such I wanted to get the lists...

I have been doing some playing with the patterns that define complex instructions, and I saw a behavior that doesn't look right. I think its a bug in the PPC backend. The 32-bit PPC .td file defines a pattern for the fnmsubs instruction like this: def : Pat<(fsub F4RC:$B, (fmul F4RC:$A, F4RC:$C)), (FNMSUBS F4RC:$A, F4RC:$C, F4RC:$B)>,

...inline. Regards, Ben [...] > The main problem that I have hit is regarding the use of CL register in the > shift instructions. The problem is that ATT syntax states that it should be > referenced as "%cl" while Intel says just "cl" but these references occur in > X86InstInfo.td and this means that it is shared between Intel and ATT > printing! For example, the shift rules: We have two different output styles for precisely that reason. > The problem is that it does not make sense to have separate rules for Intel > and ATT and as such I wanted to get the lists...

...Memory fold tables: Two way mapping of each register-form instruction to its corresponding memory-form instruction. E.g. Mapping 'X86::ADD32rr' to 'X86::ADD32rm'. Few months ago I started an effort to auto-generate the X86 memory folding tables currently held under lib/Target/X86/X86InstInfo.cpp as huge manually-maintained static arrays. Automating the tables would reduce the maintenance burden for developers to repeatedly update them with every new (foldable) instruction added to X86 backend, and would provide us with all the missing entries (mostly AVX512 instructions). After consid...