search for: ltorg

On Nov 1, 2013, at 12:06 PM, David Peixotto <dpeixott at codeaurora.org> wrote: >>> I was thinking that without the .ltorg directive the constant pool >>> would go at the end of the section. >>> >> So where does the assembler place the constant pool(s) if that directive >> isn't present? I was under the impression it was always required. > > From my understanding it is not requ...

> > I was thinking that without the .ltorg directive the constant pool > > would go at the end of the section. > > > So where does the assembler place the constant pool(s) if that directive > isn't present? I was under the impression it was always required. >From my understanding it is not required. I see that GCC...

> >>> I was thinking that without the .ltorg directive the constant pool > >>> would go at the end of the section. > >>> > >> So where does the assembler place the constant pool(s) if that > >> directive isn't present? I was under the impression it was always > required. > > > > Fro...

I'm not entirely sure what caused this, but the following code, which used to behave as expected, is now broken: ---- lolwut.c ---------------------------- void lolwut(void) { __asm __volatile ( "ldr r1, =1f \n" ".ltorg \n" "1: \n\t" : : : "r0", "r1" ); } ------------------------------------------- ~/clang -target armv7-none-eabi -O0 -c -emit-llvm lolwut.c -o lolwut.bc ~/llc -O0 lolwut.bc -o lolwut.s ---- lolwut.s ---------------------------- .file &q...

In an earlier email[1] I proposed adding support for the ldr pseud-instruction to the ARM integrated assembler. After some discussion the overall consensus seemed to be that it was worth adding. One concern was that we needed to have adequate testing. I promised to provide more details on what the behavior should be and provide some tests before starting the implementation. The FileCheck-ified

On Nov 1, 2013, at 12:15 PM, David Peixotto <dpeixott at codeaurora.org> wrote: >>>>> I was thinking that without the .ltorg directive the constant pool >>>>> would go at the end of the section. >>>>> >>>> So where does the assembler place the constant pool(s) if that >>>> directive isn't present? I was under the impression it was always >> required. >&g...

...> 8. Check that an error is issued when the constant pool would be placed too > far away I'd say this one is actually the most involved constraint but there don't actually seem to be any tests in the attached file for it. And I believe the directive Jim's referring to is ".ltorg". It's presumably going to have some interesting quirks of its own. Cheers. Tim.

Hi David, In these examples, I don’t see the directive that indicates where the assembler should place the constant pool? -Jim On Nov 1, 2013, at 11:16 AM, David Peixotto <dpeixott at codeaurora.org> wrote: > In an earlier email[1] I proposed adding support for the ldr > pseud-instruction to the ARM integrated assembler. After some discussion the > overall consensus seemed to be

Hi, What would be the proper syntax in a C file, using inline assembly, to load a immediate value into an ARM register using clang & integrated assembler? The following syntax is rejected by LLVM: // clang -target armv7em-none-eabi -mthumb #define CONSTANT 0x1234 void __attribute__((naked)) foo(void) { asm volatile ( "ldr r0, =%0 \n"

...ike you were looking at an old patch. I've attached the latest patches to this email (and a squashed version of all three for easy reading). I believe many of your concerns were addressed. See below for a detailed response. > Maybe I'm just blind, but where's the code to handle the .ltorg directive? It is implemented in patch 0003 in this email. > +typedef std::map<const MCSection *, ConstantPool> ConstantPoolMapTy; > > This feels odd to me. Can you elaborate a bit more on the data structure > choices?? I would have expected constants to be grouped together >...

...how difficult this will be to implement, but Jim also indicated it could be tricky so I believe you both :). I only have a simple test for this now, but I'd welcome suggestions on improving it or any hits on the implementation. > And I believe the directive Jim's referring to is ".ltorg". It's > presumably going to have some interesting quirks of its own. Yes, I replied to Jim saying that I was planning to implement .ltorg in a separate step. -------------- next part -------------- A non-text attachment was scrubbed... Name: ldr_pseudo_errors.s Type: application/octe...

...non-empty pools) to see if > there was a subsections-via-symbols directive in there anywhere. This seems to be a reasonable choice. It seems it would still be difficult to detect all the cases where we could run into trouble. For example, something like _foo: ldr r1, =0x12345678 _bar: ... .ltorg If bar gets deleted we would still have the wrong offsets. > Anyways, the main point of all of this is to reinforce the "there be > dragons here" nature of this feature. It interacts with other parts of the > assembler and the underlying assumptions of the platform in interesti...

Hi David, Maybe I’m just blind, but where’s the code to handle the .ltorg directive? Is that a separate patch, maybe? Without that, this is not going to be usable in any circumstance using subsections-via-symbols. +typedef std::map<const MCSection *, ConstantPool> ConstantPoolMapTy; This feels odd to me. Can you elaborate a bit more on the data structure choices?...

...the information through from where it starts to where it’ll be diagnosable (post-layout and relaxation in the object writer, probably). I see. Yes the ARM documents say it is the user’s responsibility to ensure the constant can be placed in a constant pool that is reachable by the instruction. LTORG is the arm directive that forces the assembler to emit the current constant pool. The corresponding gcc directive is .ltorg. Both armasm and gcc give an error if the constant pool is placed too far away. Tangentially related, I would also very strongly oppose changing the compiler’s asm printer...

Moving discussion to llvm-commits now that I have a more developed implementation: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131111/195401. html > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of David Peixotto > Sent: Tuesday, November 12, 2013 11:09 AM > To: 'Amara Emerson' >

...ormation through from where it starts to where it’ll be diagnosable (post-layout and relaxation in the object writer, probably). > > I see. Yes the ARM documents say it is the user’s responsibility to ensure the constant can be placed in a constant pool that is reachable by the instruction. LTORG is the arm directive that forces the assembler to emit the current constant pool. The corresponding gcc directive is .ltorg. Both armasm and gcc give an error if the constant pool is placed too far away. Sounds good. I’m not hugely fond of the assembler doing that sort of thing, but it’s not too h...

...ome of my confusion. I suspect some (mis)threading of emails got in the way. Thanks again for your patience working through this. Responses to a few specific questions below, and I’ll follow up on the new patch separately. >> Maybe I'm just blind, but where's the code to handle the .ltorg directive? > > It is implemented in patch 0003 in this email. Excellent. > >> +typedef std::map<const MCSection *, ConstantPool> ConstantPoolMapTy; >> >> This feels odd to me. Can you elaborate a bit more on the data structure >> choices?? I would have e...

Short version: If the integrated assembler accepted assembly strings as input, more targets could take advantage of integrated assembly. The longer version: For a given assembly statement, my out-of-tree target has complex instruction selection logic -- more so than the in-tree targets. This target uses variable length instructions and a laborious hierarchy of tblgen AsmOperands to do the job.

On Oct 25, 2013, at 3:53 PM, David Peixotto <dpeixott at codeaurora.org> wrote: > 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

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: