search for: x86instrcontrol

Hi, What is the calling conventions for YMM. According to documents I saw till now, the YMMs are scratch and not saved in callee. This is also the default behavior of the Intel Compiler. In X86InstrControl.td the YMMs are not in "defs" set of call. - Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distributio...

...nfo::getCalleeSavedRegs, so some xmm regs were included >> (similar to what was done for win64). But the result wasn't what I >> expected - the callee now indeed saved/restored all the xmm regs I >> added, however the calling code did not change at all... > > Look in X86InstrControl.td. The call instructions are all prefixed > by: > > let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, > FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, > XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, XMM8, XMM9, XMM10, > XMM11, XMM12,...

Hi, > What is the calling conventions for YMM. According to documents I saw till now, the YMMs are scratch and not saved in callee. > This is also the default behavior of the Intel Compiler. x86_64 Non-windows targets use the rules defined in the x86_64 abi! > In X86InstrControl.td the YMMs are not in "defs" set of call. The XMMs are subregisters of YMMs, and they are in the list, that should be sufficient for clobbering the YMM ones. -- Bruno Cardoso Lopes http://www.brunocardoso.cc

On Oct 20, 2010, at 7:46 AM, Roland Scheidegger wrote: > On 20.10.2010 05:00, Jakob Stoklund Olesen wrote: >> Look in X86InstrControl.td. The call instructions are all prefixed >> by: >> >> let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, >> FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, >> XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, XMM8, XMM9, XMM10,...

(repost with right sender address) On 20.10.2010 18:13, Jakob Stoklund Olesen wrote: > On Oct 20, 2010, at 7:46 AM, Roland Scheidegger wrote: > >> On 20.10.2010 05:00, Jakob Stoklund Olesen wrote: >>> Look in X86InstrControl.td. The call instructions are all prefixed >>> by: >>> >>> let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, >>> FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, >>> XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7,...

...list in > X86RegisterInfo::getCalleeSavedRegs, so some xmm regs were included > (similar to what was done for win64). But the result wasn't what I > expected - the callee now indeed saved/restored all the xmm regs I > added, however the calling code did not change at all... Look in X86InstrControl.td. The call instructions are all prefixed by: let Defs = [RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11, FP0, FP1, FP2, FP3, FP4, FP5, FP6, ST0, ST1, MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, XMM8...

Thanks for giving it a look! On 19.10.2010 23:21, Jakob Stoklund Olesen wrote: > On Oct 19, 2010, at 11:40 AM, Roland Scheidegger wrote: > >> So I saw that the code is doing lots of register >> spilling/reloading. Now I understand that due to calling >> conventions, there's not really a way to avoid this - I tried using >> coldcc but apparently the backend

...r YMM registers on AVX Hi, > What is the calling conventions for YMM. According to documents I saw till now, the YMMs are scratch and not saved in callee. > This is also the default behavior of the Intel Compiler. x86_64 Non-windows targets use the rules defined in the x86_64 abi! > In X86InstrControl.td the YMMs are not in "defs" set of call. The XMMs are subregisters of YMMs, and they are in the list, that should be sufficient for clobbering the YMM ones. -- Bruno Cardoso Lopes http://www.brunocardoso.cc --------------------------------------------------------------------- Intel I...

> But where is the flat set? Maybe I can debug and check what is going on. The MCInstrDesc are in a table in lib/Target/PowerPC/PPCGenInstrInfo.inc of your build directory. > Some additional information: > > MCInst opcode: 0x7cb > Decode Index: 0x1e I had assumed this would have dissembled to '// Inst #234 = BC' which does have the branch flag set, but I think that