similar to: [LLVMdev] Nested functions

Hi Duncan, Thanks for your reply. I did try the method suggested by you. I got a foo.bc with -emit-llvm switch. llc on foo.bc gets me the same assertion failure, as you pointed out. Then I ran bugpoint to generate bugpoint-reduced-simplified.bc and bugpoint-reduced-function.bc. My previous experience is that if I compile either if them, I would get the same failure as I did with foo.bc. That is

Hi Bharadwaj, > I get the following error during compilation using the LLVM cross-compiler > (x86_64->arm). > > error: nested functions are disabled, use -fnested-functions to re-enable yes, nested functions are disabled by default in llvm-gcc (not sure why - maybe a historical hang over from the days when they were not supported?). > With -fnested-functions switch, I get the

On Mar 4, 2009, at 1:33 PM, S. Bharadwaj Yadavalli wrote: > Hi Duncan, > > Thanks for your reply. > > I did try the method suggested by you. I got a foo.bc with -emit- > llvm switch. llc on foo.bc gets me the same assertion failure, as > you pointed out. > > Then I ran bugpoint to generate bugpoint-reduced-simplified.bc and > bugpoint-reduced-function.bc. My

Folks, I'm working on bug 16387: "clang doesn't produce ARM EABI-compliant modulo runtime function" http://llvm.org/bugs/show_bug.cgi?id=16387 And I need some pointers. I've changed ARMISelLowering::ARMTargetLowering::ARMTargetLowering() to associate __aeabi_idivmod variants to RTLIB::{U,S}DIVREM_* library calls, but now I need to teach the expansion that on AEABI case,

John, I've moved with patches to HEAD and unfortunately the comments about disabling tailcalls do not go away with this update. Please see ARMTargetLowering::LowerCall in lib/Target/ARM/ARMISelLowering.cpp line 1208 and later. It looks like man can use -arm-tail-calls, but one never knows how good it is since the comment tells it clearly: // Temporarily disable tail calls so things

On Jun 8, 2009, at 2:42 PM, robert muth wrote: > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> > wrote: >> >> On Jun 7, 2009, at 6:59 AM, robert muth wrote: >> >>> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >>> wrote: >>>> +cl::opt<std::string>

Hello Cameron, thanks a lot for your fast answer, which just makes me curious if making ARM tailcalls on par with x86 in the future is on some of the development plans already? If not, then what do you think is the complexity of such work? Thanks! Karel On 06/17/11 10:41 PM, Cameron Zwarich wrote: > They work pretty well now, at least on Thumb2 / Darwin. It is still fairly conservative

Hi Bitter Melon! If it's not too much trouble, could you add a check box to the LLVM demo page to pass the -fnested-functions option to llvm-gcc? I'm interested in studying how nested functions are implemented, but haven't yet been able to get llvm-gcc built on my own system. Thanks! Eric

On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jun 7, 2009, at 6:59 AM, robert muth wrote: > >> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >> wrote: >>> +cl::opt<std::string> FlagJumpTableSection("jumptable-section", >>> +                                          

I'm getting this build error with -Werror: [off-opt] : [llvm] cc1plus: warnings being treated as errors [off-opt] : [llvm] /ptmp/dag/llvm/official/llvm/lib/Target/ARM/ARMISelLowering.cpp: In member function 'llvm::MachineBasicBlock* llvm::ARMTargetLowering::EmitAtomicBinary64(llvm::MachineInstr*, llvm::MachineBasicBlock*, unsigned int, unsigned int, bool, bool) const': [off-opt]

They work pretty well now, at least on Thumb2 / Darwin. It is still fairly conservative about when to use tail calls, and doesn't support GuaranteedTailCallOpt, which might be necessary for GHC. Cameron On Jun 17, 2011, at 1:31 PM, Karel Gardas wrote: > > John, > > I've moved with patches to HEAD and unfortunately the comments about > disabling tailcalls do not go

Hi Eric, > If it's not too much trouble, could you add a check box to the LLVM demo > page to pass the -fnested-functions option to llvm-gcc? I'm interested > in studying how nested functions are implemented, but haven't yet been > able to get llvm-gcc built on my own system. I turned it on unconditionally. Meow! Bitter Melon.

Hi, This results in the following warning when using C++ as a source language: cc1plus: warning: command line option "-fnested-functions" is valid for C/ObjC but not for C++ Best regards, Victor -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands Sent: 02 June 2009 10:21 To: LLVM Developers Mailing List

Evan: Sorry for the late follow up, I was out of town last week. Enclosed please find the updated patch including all your suggestions and a dejagnus test. Robert On Thu, Jun 11, 2009 at 2:27 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jun 8, 2009, at 2:42 PM, robert muth wrote: > > > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com>

I don't know if GuaranteedTailCallOpt is in anyone's plans. It might be a good idea to implement some time. I am not sure what GHC's exact needs are, though. Cameron On Jun 17, 2011, at 1:49 PM, Karel Gardas wrote: > > Hello Cameron, > > thanks a lot for your fast answer, which just makes me curious if making ARM tailcalls on par with x86 in the future is on some of

On Jun 16, 2011, at 1:35 PM, Karel Gardas wrote: > I'm working on implementing GHC specific call convention into LLVM 2.9. I've chosen LLVM 2.9 as a kind of stable reference point and I would like to know how mature is ARM code generation chain inside this release. I've had a hope that perhaps Apple as a main sponsor of LLVM is using LLVM for their ARM based iOS software

Hi list: I have been trying to get my feet wet with the ARM backend. As a warmup exercise I wanted to be able to move jumptables especially large ones out of the code section. Currently the idiom for jump tables loooks like this // .set PCRELV0, (.LJTI9_0_0-(.LPCRELL0+8)) // .LPCRELL0: // add r3, pc, #PCRELV0 // ldr pc, [r3, +r0, lsl #2] // .LJTI9_0_0: //

Hi folks, me again, So, I want to implement a simple optimization in a NEON case I've seen these days, most as a matter of exercise, but it also simplifies (just a bit) the code generated. The case is simple: uint32x2_t x, res; res = vceq_u32(x, vcreate_u32(0)); This will generate the following code: ; zero d16 vmov.i32 d16, #0x0 ; load a

Hello, I'm working on implementing GHC specific call convention into LLVM 2.9. I've chosen LLVM 2.9 as a kind of stable reference point and I would like to know how mature is ARM code generation chain inside this release. I've had a hope that perhaps Apple as a main sponsor of LLVM is using LLVM for their ARM based iOS software development, but I'm not sure if I'm right

Hi Renato, > * Have some call-back mechanism, possibly upon a flag > (HasSpecialDivRemLowering), and update the remainder result If you setOperationAction on SDIVREM and UDIVREM to Custom you can expand the rtlib call appropriately yourself. There's precedent for sincos on Darwin systems (both ARM and x86) and in AArch64 for basically every operation on fp128. Cheers. Tim.