Hi all, I analyzed more and ready (1) to describe the problem and (2) I have a proposal. (1) Problem description: In X86_64 target the Code Model is "Large". It means that address is 64-bit and IP-relative memory operand can't be used in this case. (Because in IP-relative memory operand the displacement is 32-bit). In order to load constant, we use 2 instructions. movabsq $.LCPI0_0, %rcx vmulpd (%rcx), %ymm0, %ymm0 It happens because .LCPI0_0 is in .rodata section and instruction itself is in .text. If I put the constant in .text, the code will look much better: vmulpd .LCPI0_0(%rip), %ymm0, %ymm0 (2) Proposal Define one more Code Model, let's say "LargeNearConst", which will allow to put constants in .text. I'd like to hear people's opinion. Will it help other targets? I'm ready to send a patch. Thank you. - Elena -----Original Message----- From: Tim Northover [mailto:t.p.northover at gmail.com] Sent: Tuesday, June 25, 2013 15:08 To: Demikhovsky, Elena Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Contants generation Hi again, Actually, I've just been looking at the existing code and the ARM solution may be over-complicated for this situation. You should be able to override EmitConstantPool directly, or possibly even just override getSectionForConstantKind in X86LinuxTargetObjectFile (and perhaps others) to return .text. Tim. --------------------------------------------------------------------- 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 distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Hi Elena,> (2) Proposal > Define one more Code Model, let's say "LargeNearConst", which will allow to put constants in .text.Isn't that a little heavy-handed? The large model only requires the less efficient access for symbols we can't control, and in fact x86 still uses pc-relative conditional branches within a function so it can't pretend to support a single function >2GB in code size even now. I think that the improved behaviour for consts should be acceptable in the large model. But that's just me.> I'd like to hear people's opinion. Will it help other targets? I'm ready to send a patch.An analogous improvement would be useful for AArch64, which means that if the new model *is* justified it would probably be useful there too. Cheers. Tim.
> I think that the improved behavior for consts should be acceptable in the large model. But that's just me.By default, all constants should be in a special read-only section, and this section may be far from the text section. I'm working with JIT model or with only one object file. The code model, when all constants are near, we can call "LargeJIT". (Is it sounds better then LargeNearConst?) For X86 target JITDefault will be translated CodeModel::LargeJIT for x64 and CodeModel::Small for 32-bit. And the TargetLoweringObjectFile already has CodeModel inside. So the code will look like : const MCSection * TargetLoweringObjectFile::getSectionForConstant(SectionKind Kind) const { if (getCodeModel() == CodeModel::LargeJIT) return TextSection; if (Kind.isReadOnly() && ReadOnlySection != 0) return ReadOnlySection; return DataSection; } - Elena -----Original Message----- From: Tim Northover [mailto:t.p.northover at gmail.com] Sent: Tuesday, June 25, 2013 23:31 To: Demikhovsky, Elena Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Contants generation - proposal Hi Elena,> (2) Proposal > Define one more Code Model, let's say "LargeNearConst", which will allow to put constants in .text.Isn't that a little heavy-handed? The large model only requires the less efficient access for symbols we can't control, and in fact x86 still uses pc-relative conditional branches within a function so it can't pretend to support a single function >2GB in code size even now. I think that the improved behaviour for consts should be acceptable in the large model. But that's just me.> I'd like to hear people's opinion. Will it help other targets? I'm ready to send a patch.An analogous improvement would be useful for AArch64, which means that if the new model *is* justified it would probably be useful there too. Cheers. Tim. --------------------------------------------------------------------- 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 distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.