similar to: [LLVMdev] [LLVM] Forward temp label references on ARM in LDR with .ltorg in inline assembly are broken in trunk

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. >

> > 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 will place it at the end of the section. I don't

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

> >>> 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

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 David, > 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.

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

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' >

> There's still a problem for Darwin, or any other platform that use > subsections-via-symbols type layout tricks, though. There's no assembler- > time way to know how far apart the atoms in the section will be at > runtime, as the linker can, and will, move things around. Hmm, yes that does sound quite tricky. How do we currently deal with that for other pc-relative loads.

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?? I would have expected

Hi Jim, Thanks for the review. It seems like 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

From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Friday, October 25, 2013 4:31 PM To: David Peixotto Cc: Renato Golin; LLVM Dev Subject: Re: [LLVMdev] Add support for ldr pseudo instruction in ARM integrated assembler 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.

On Oct 25, 2013, at 6:14 PM, David Peixotto <dpeixott at codeaurora.org> wrote: > From: Jim Grosbach [mailto:grosbach at apple.com] > Sent: Friday, October 25, 2013 4:31 PM > To: David Peixotto > Cc: Renato Golin; LLVM Dev > Subject: Re: [LLVMdev] Add support for ldr pseudo instruction in ARM integrated assembler > > > On Oct 25, 2013, at 3:53 PM, David Peixotto

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"

On Tue, Jan 24, 2012 at 08:36:17AM -0800, Esperanza de Escobar wrote: > No one is arguing that there aren't ABI specs or LLVM design > guidelines that say that unaligned accesses "should not", "could not" > or "aren't guaranteed to" work, because it's besides the point. No, it is the core of the issue. Standard C gives the compiler certain

Hi Tim, > > 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. I put the test in a separate file and forgot to attach it earlier. I've attached it to this email. I can't say how

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

On Dec 17, 2013, at 11:33 AM, David Peixotto <dpeixott at codeaurora.org> wrote: > Hi Jim, > > Thanks for the review. It seems like 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. > Ack!

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:

John, I'm still not sure what you're talking about, I have included the assembly output from two compilations, one with a user explicit catch-all, one with only an implicit cleanup, the DWARF Action Table and Types Table are absolutely identical, as are the indexes used to reference the Action Table from the region maps. -Peter Lawrence.