search for: constpool

Hi All, In SVN head, MipsISelDAGToDAG.cpp has the following optimization: // Operand is a result from an ADD. if (Addr.getOpcode() == ISD::ADD) { // When loading from constant pools, load the lower address part in // the instruction itself. Example, instead of: // lui $2, %hi($CPI1_0) // addiu $2, $2, %lo($CPI1_0) // lwc1 $f0, 0($2) // Generate: //

...xt section is reasonably simple, though doesn't have a generic "pleasePutConstantsAfterFunctions()" call in LLVM. A good place to start would be the reverse of my recent patch to AArch64 which removed the entire ConstantIslands thing. It looks like the key points are creating a "CONSTPOOL_ENTRY" "instruction" which is emitted in the AsmPrinter. A relatively simple pass should be able to convert constpool entries as LLVM sees them into such instructions (see "doInitialPlacement"). Most of the complexity is in moving the constants around so that they're a...

I am working towards a more complete solution for large constants in mips 16 (ala Arm constant islands and such). That is part of why I'm busy expanding all macros being emitted in the mips 16 compiler (almost done). I'm wondering if there is a poor mans approach for large constants that can be done very simply that I can add just for now. Gcc mips 16 places them after the function

...64, i32, ...)* @llvm.experimental.stackmap(i64 0, i32 0, i64 9223372036854775807) ret void } The issue is that 9223372036854775807 (decimal for 0x7fffffffffffffff) is the "empty key" for an int64_t, and in StackMaps::recordStackMapOpers we crash when we try to insert this as a key into ConstPool. The this happens if we change the constant to be the tombstone. Two potential fixes I can think of: 1. have some special logic to remember the offsets for the tombstone and empty i64 constants. This can easily be tracked using two "Optional<int>" fields. 2. change Co...

Hi, I'd like to generate constants inside .text in order to use ip-relative loads, when the code model is "large". How can I do this? (I'm on X86_64 linux) Thank you. - Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the

...to generate constants inside .text in order to use ip-relative > loads, when the code model is “large”. I don't think this is a sequence the x86 backend supports at the moment, but it is how ARM handles its constant-pools. The outline is that you have a pass which looks through a functions constpool uses and emits a pseudo-instruction for each, which is then handled in the AsmPrinter. ARM has the added complication that the instructions accessing these constants are of limited range, which means lots of extra complexity making sure they can be reached when needed. This is probably unnecessary...

...le, though > doesn't have a generic "pleasePutConstantsAfterFunctions()" call in > LLVM. > > A good place to start would be the reverse of my recent patch to > AArch64 which removed the entire ConstantIslands thing. It looks like > the key points are creating a "CONSTPOOL_ENTRY" "instruction" which is > emitted in the AsmPrinter. A relatively simple pass should be able to > convert constpool entries as LLVM sees them into such instructions > (see "doInitialPlacement"). > > Most of the complexity is in moving the constants arou...

...ich is something that would definitely be needed. From my first glance it looks like creating and placing the constant pool is the tricky part in actually implementing this feature. This is where things get interesting. IIRC, the ARM tools rely on the user to locate the constant pools (there’s a .constpool directive or something like that which spurs out whatever constants have been collected up to that point. It’s up to the user to make sure that the pool is in range for any load instructions referencing it. I assume a diagnostic is expected if they’re not, which is the part that would be tricky her...

...is something that would definitely be needed. From my first glance it looks like creating and placing the constant pool is the tricky part in actually implementing this feature. This is where things get interesting. IIRC, the ARM tools rely on the user to locate the constant pools (there’s a .constpool directive or something like that which spurs out whatever constants have been collected up to that point. It’s up to the user to make sure that the pool is in range for any load instructions referencing it. I assume a diagnostic is expected if they’re not, which is the part that would be tricky her...

Hi Renato, Thanks for the thoughtful reply. Please find my thoughts below. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Friday, October 25, 2013 1:11 PM To: David Peixotto Cc: LLVM Dev; Logan Chien; Gabor Ballabas; Rafael Espíndola; Richard Barton; Amara Emerson Subject:

...thing that would definitely be needed. From my first glance it looks like creating and placing the constant pool is the tricky part in actually implementing this feature. > > This is where things get interesting. IIRC, the ARM tools rely on the user to locate the constant pools (there’s a .constpool directive or something like that which spurs out whatever constants have been collected up to that point. It’s up to the user to make sure that the pool is in range for any load instructions referencing it. I assume a diagnostic is expected if they’re not, which is the part that would be tricky her...

...itely be needed. From my first glance it looks like creating and > placing the constant pool is the tricky part in actually implementing this > feature.**** > > > This is where things get interesting. IIRC, the ARM tools rely on the user > to locate the constant pools (there’s a .constpool directive or something > like that which spurs out whatever constants have been collected up to that > point. It’s up to the user to make sure that the pool is in range for any > load instructions referencing it. I assume a diagnostic is expected if > they’re not, which is the part that...