similar to: [LLVMdev] Problems with 64-bit register operands of inline asm on ARM

On 13 March 2013 13:43, Måns Rullgård <mans at mansr.com> wrote: > One possible fix, which I have tested, is to look for the specific > instructions requiring such a pair (LDRD/STRD and LDREXD/STREXD) in > addition to the 'H' modifier. However, there are probably other > creative ways in which inline asm might rely on the specific pairing. > Hi Mans, Either that

Hi Renato, It seems to me that LLVM doesn’t parse the inline asm body. It just checks the constraints, (ie. Input/output interface). During ASM writing, it then binding those constraints to placeholders like %0, %1. So it a constraint is a 64-integer type, it *probably* needs paired GPR. Weiming Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The

On Mar 13, 2013, at 10:15 AM, Weiming Zhao <weimingz at codeaurora.org> wrote: > Hi Renato, > > It seems to me that LLVM doesn’t parse the inline asm body. It just checks the constraints, (ie. Input/output interface). During ASM writing, it then binding those constraints to placeholders like %0, %1. This is correct. > So it a constraint is a 64-integer type, it *probably*

Hi Måns, Always forcing 64-bit operands into even/odd pairs may lead to subpoptimal register allocation because not all 64 bit data requires paired regs. It seems there is no general pattern to match. Maybe we should treat it case by case. Jakob, do you have any suggestions? Thanks, Weiming Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Jim Grosbach <grosbach at apple.com> writes: > On Mar 13, 2013, at 11:21 AM, Måns Rullgård <mans at mansr.com> wrote: > >> Jim Grosbach <grosbach at apple.com> writes: >> >>> On Mar 13, 2013, at 11:01 AM, Renato Golin <renato.golin at linaro.org> >>> wrote: >>> >>>> On 13 March 2013 17:57, Jim Grosbach <grosbach

Jim Grosbach <grosbach at apple.com> writes: > On Mar 13, 2013, at 11:01 AM, Renato Golin <renato.golin at linaro.org> > wrote: > >> On 13 March 2013 17:57, Jim Grosbach <grosbach at apple.com> wrote: >>> It seems to me that LLVM doesn’t parse the inline asm body. It just >>> checks the constraints, (ie. Input/output interface). During ASM

On Wed, Mar 13, 2013 at 1:04 PM, Måns Rullgård <mans at mansr.com> wrote: > Jim Grosbach <grosbach at apple.com> writes: > > > On Mar 13, 2013, at 11:21 AM, Måns Rullgård <mans at mansr.com> wrote: > > > >> Jim Grosbach <grosbach at apple.com> writes: > >> > >>> On Mar 13, 2013, at 11:01 AM, Renato Golin <renato.golin at

On Mar 13, 2013, at 11:21 AM, Måns Rullgård <mans at mansr.com> wrote: > Jim Grosbach <grosbach at apple.com> writes: > >> On Mar 13, 2013, at 11:01 AM, Renato Golin <renato.golin at linaro.org> >> wrote: >> >>> On 13 March 2013 17:57, Jim Grosbach <grosbach at apple.com> wrote: >>>> It seems to me that LLVM doesn’t parse the

On Mar 13, 2013, at 11:01 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 13 March 2013 17:57, Jim Grosbach <grosbach at apple.com> wrote: >> It seems to me that LLVM doesn’t parse the inline asm body. It just checks the constraints, (ie. Input/output interface). During ASM writing, it then binding those constraints to placeholders like %0, %1. > This is

On 13 March 2013 17:57, Jim Grosbach <grosbach at apple.com> wrote: > It seems to me that LLVM doesn’t parse the inline asm body. It just checks > the constraints, (ie. Input/output interface). During ASM writing, it then > binding those constraints to placeholders like %0, %1. > > This is correct. > Ok, so maybe checking all possible ways to require paired registers is

On 7/16/14, 6:09 PM, sgundapa wrote: > I see a couple of issues here. > > If I include .S files for ARM, the –no-integrated-as path complains about > Assembler errors. > > The integrated-as path works fine though. > These are very likely just differences between the old ARM assembler syntax and the new 'Unified' syntax. Can you use an assembler that accepts UAL

Hi, I think I discovered a major armv7 optimization bug in Clang. I create a simple test case which exhibits the issue. When you compile the attached file for armv7 with optimizations turned on (O2, O3 or Os), the binary generated led to a crash. The issue can't be reproduced when using GCC 4.2. It can't be reproduced with Clang when the optimization is turned off (O0). This issue can be

The problem is in your code, not the compiler. You're casting an unaligned char* to an int*, even though an int* pointer must be 4-byte aligned in every ARM ABI that I've ever seen. On Jan 23, 2012, at 6:14 AM, Alexandre Colucci wrote: > Hi, > > I think I discovered a major armv7 optimization bug in Clang. I create a simple test case which exhibits the issue. > When you

In practice all Apple hardwares support misaligned accesses for single-register loads and stores. If a pointer is not aligned, LLVM should not use the double-register loads and stores. It should keep the two single-register loads instead of trying to optimize them as one unsupported double-register load. Note that this code compiled with GCC 4.2 runs perfectly whereas LLVM will produce a binary

Hi, I'm wondering if LLVM plans to support paired register constraints for 64-bit data. Take ARM for example, the atomic i64 value read/write instuctions: ldrexd/strexd, require aligned register pairs (even/odd). Currently, in LLVM ARM (ARMISelDAGToDAG.cpp), ldrexd/strexd get hard coded registers (R0,R1) before register allocation via intrinsic. It would be neater if there is a

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. The point is that unaligned 32-bit loads and stores *work in practice* on every single ARM device Apple has ever manufactured. I'm not a hardware person, but

> On Apr 2, 2015, at 2:07 PM, Tom Stellard <tom at stellard.net> wrote: > > On Thu, Apr 02, 2015 at 01:35:55PM -0700, Pete Cooper wrote: >> Hi James, Jim >> >> If you *really* want this to work in selection DAG then there is a solution, but its not pretty. >> >> First make i64 not be legal. Then, assuming the regclass you gave has some subregs, you

> Note that this code compiled with GCC 4.2 runs perfectly whereas LLVM will produce a binary that crashes: LLVM breaks existing source code. On this point: This is not uncommon - and the very nature of "Undefined Behaviour". This reason alone is not enough to justify a change to Clang. We/you would need to show that the behaviour is defined & Clang is violating that definition.

I have two questions regarding MachineMemOperands and dependence information. Q1) I noticed that MachineMemOperands are lost when two LDRs are combined and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. (before optimization) %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; mem:LD4[%uglygep10] %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14,

Hi Lang and Arnaud, I've been testing out the PBQP allocator for Thumb-2 and have ran into a problem I'd love to get your input on. The problem is exemplfied in the codegen for the function @bar in the attached IR file: bar: push {r4, lr} sub sp, #12 (1) movw r2, :lower16:.L_MergedGlobals (1) movt r2, :upper16:.L_MergedGlobals ldm.w r2,