similar to: Difference between -mattr=+soft-float and -float-abi=soft

Hi Moritz, On 26 September 2017 at 09:09, Moritz Angermann via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I’ve run into a case where `llc -mattr=+soft-float` for > "armv7-unknown-linux-androideabi” segfaults, while > `llc -float-abi=soft` does not. Similarly if the > "target-features"="+soft-float” metadata is embedded, > llc segfaults. The float-abi

Hi Tim, Ohh, I completely forgot to attach the source. Running this with: $ llc -O2 -mcpu=generic HeapStackCheck.ll -mattr=+soft-float -o HeapStackCheck.s results in 0 llc 0x000000010fea65e6 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37 1 llc 0x000000010fea5b3a llvm::sys::RunSignalHandlers() + 83 2 llc

Hi Tim, thanks for the swift response! @debug is defined in the same module, which makes this all the more confusing. The target information from the working example are: target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64" target triple = "armv6kz--linux-gnueabihf" from the ghc produced module: target datalayout =

> On Mar 14, 2017, at 3:02 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Mar 11, 2017, at 4:30 PM, Moritz Angermann via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi Matthias, >> >> what I’m observing right now is that replacing opt+llc with an clang invocation, and >> subsequently fewer intermediate files,

Hi Matthias, what I’m observing right now is that replacing opt+llc with an clang invocation, and subsequently fewer intermediate files, increases the consumed time with -O0 by 200%. We used to always run opt with -mem2reg -globalopt, and I believe those are not part of -O0 (is there an easy way to list all passes that -OX flags to clang imply for the optimizer and code gen?). Could the IR imply

Hi, When setting -mattr option on X86, I would like to treat MMX separately from SSE levels. This would allow a client who sets the attributes directly to set the SSE level independent of MMX, e.g., llc -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while llc -march=x86 -mattr=mmx -mattr=sse42 will get mmx and sse42. If anyone objects to this change, please let me

Might you instead consider just adding a -disable-mmx option? Preston On Thu, 2008-20-11 at 02:57 -0500, Mon Ping Wang wrote: > Hi, > > When setting -mattr option on X86, I would like to treat MMX > separately from SSE levels. This would allow a client who sets the > attributes directly to set the SSE level independent of MMX, e.g., llc > -march=x86 -mattr=sse41, one would get

On Nov 19, 2008, at 11:57 PMPST, Mon Ping Wang wrote: > Hi, > > When setting -mattr option on X86, I would like to treat MMX > separately from SSE levels. This would allow a client who sets the > attributes directly to set the SSE level independent of MMX, e.g., llc > -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while > llc -march=x86 -mattr=mmx

Hi Dale, I will not change the default. I would dislike to see any regressions due to this type of change. -- Mon Ping On Nov 20, 2008, at 10:12 AM, Dale Johannesen wrote: > > On Nov 19, 2008, at 11:57 PMPST, Mon Ping Wang wrote: > >> Hi, >> >> When setting -mattr option on X86, I would like to treat MMX >> separately from SSE levels. This would allow a

On Nov 20, 2008, at 8:31 AM, Preston Gurd wrote: > Might you instead consider just adding a -disable-mmx option? I agree, this is a better approach. This distinguishes between capabilities of the chip and the desire to codegen specific vectors one way or another. -Chris > > Preston > > On Thu, 2008-20-11 at 02:57 -0500, Mon Ping Wang wrote: >> Hi, >> >>

Hi all, I was wondering if there is a defined ABI for passing vector as parameter for ARM target. For instance is this valid to write .ll statement like: ; ModuleID = 'bugconv.ll' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-n32" target triple = "thumbv7-none-linux-androideabi" define

Hi Rotem, Thanks for the quick answer, how do I know which type is legal/illegal with respect to calling convention ? Best Regards Seb > -----Original Message----- > From: Rotem, Nadav [mailto:nadav.rotem at intel.com] > Sent: Thursday, July 05, 2012 11:21 AM > To: Sebastien DELDON-GNB; llvmdev at cs.uiuc.edu > Subject: RE: Vector argument passing abi for ARM ? > > The

Hi Duncan, I also thought it was a bug, especially since it worked with LLVM 3.0, but since it is not defined by ABI, I was not sure if I need to submit it as a BUG. I wanted to be sure that it is an actual BUG before submitting it and got the not-a-bug answer. Here is a small example to reproduce the problem I'm experiencing: ; ModuleID = 'bugparam.ll' target datalayout =

Hi Sebastien, > Thanks for the quick answer, how do I know which type is legal/illegal with respect to calling convention ? the code generators are supposed to produce working code no matter what the parameter type is. The fact that the ARM ABI doesn't specify how <2 x i8> is passed just means that the code generators can pass it using whatever technique it feels like (since it

The argument passing calling convention is undefined for illegal types, such as <2 x i8>. The invalid misaligned loads on ARM sounds like a bug in the ARM backend. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sebastien DELDON-GNB Sent: Thursday, July 05, 2012 12:14 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Vector

Hi *, in the process of improving the ios experience with ghc, I ran into the following issue: the produced llvm code[1] compiles for `armv7-apple-darwin`, unless optimization level is 0, however it fails to compile at all for `armv7-apple-ios`. I was able to reduce the produced code, while retaining the compilation issue on `armv7-apple-ios` to the following sample case: —————————————————————

Hi Sebastien, > I also thought it was a bug, especially since it worked with LLVM 3.0, but since it is not defined by ABI, I was not sure if I need to submit it as a BUG. yes it is a bug. > I wanted to be sure that it is an actual BUG before submitting it and got the not-a-bug answer. I didn't read Nadav's reply as saying there was no bug, in fact he explicitly said in his email

Summary ======= There is a need for dedicated continuation-passing style (CPS) calls in LLVM to support functional languages. Herein I describe the problem and propose a solution. Feedback and/or tips are greatly appreciated, as our goal is to implement these changes so they can be merged into LLVM trunk. Problem ======= Implementations of functional languages like Haskell and ML (e.g., GHC

> The semantics around inlining alone are problematic enough to warrant serious hesitation. There are nicer ways to embed CPS call/return into LLVM; I just figured that there would not be much support for adding a new terminator because it would change a lot of code. Ideally we would have a block terminator like: cps call ghccc @bar (.. args ..) returnsto label %retpt Where the

> Is there a reason you can't use the algorithm from the paper "A Correspondence between Continuation Passing Style and Static Single Assignment Form" to convert your IR to LLVM's SSA IR? Yes, there are a few reasons. Undoing the CPS transformation earlier in the pipeline would mean that we are using LLVM's built-in stack. The special layout and usage of the stack in