similar to: [LLVMdev] Problem with ALWAYS_INLINE

Hi everyone, clang currently implements the 'flatten' function attribute by marking all calls to not 'noinline' functions with 'always_inline'. In effect, only the first level of calls is inlined, not all calls recursively (like gcc does). We briefly discussed possible solutions on IRC: We could add an equivalent LLVM attribute for functions (e.g. 'flatten'). The

On Mar 15, 2009, at 6:16 PM, Nick Lewycky wrote: > Pierre Habouzit wrote: >> [ please CC: me as I'm not subscribed ] >> >> On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla- >> daemon at cs.uiuc.edu wrote: >>> http://llvm.org/bugs/show_bug.cgi?id=3756 >>> >>> Chris Lattner <clattner at apple.com> changed: >>> >>>

Pierre Habouzit wrote: > [ please CC: me as I'm not subscribed ] > > On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla-daemon at cs.uiuc.edu wrote: >> http://llvm.org/bugs/show_bug.cgi?id=3756 >> >> Chris Lattner <clattner at apple.com> changed: >> >> What |Removed |Added >>

[ please CC: me as I'm not subscribed ] On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla-daemon at cs.uiuc.edu wrote: > http://llvm.org/bugs/show_bug.cgi?id=3756 > > Chris Lattner <clattner at apple.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- >

Dan Gohman wrote: > On Mar 15, 2009, at 6:16 PM, Nick Lewycky wrote: > >> Pierre Habouzit wrote: >>> [ please CC: me as I'm not subscribed ] >>> >>> On Wed, Mar 11, 2009 at 04:13:34AM +0000, bugzilla- >>> daemon at cs.uiuc.edu wrote: >>>> http://llvm.org/bugs/show_bug.cgi?id=3756 >>>> >>>> Chris Lattner

> -----Original Message----- > From: Dmitry N. Mikushin [mailto:maemarcus at gmail.com] > Sent: Wednesday, May 16, 2012 5:44 AM > To: LLVM-Dev > Cc: Justin Holewinski > Subject: NVPTX: __iAtomicCAS support ? > > Dear colleagues, > > I'm looking if we can replace nvopencc with LLVM NVPTX in our project. > It turns NVPTX won't work with the code nvopencc

Dear colleagues, I'm looking if we can replace nvopencc with LLVM NVPTX in our project. It turns NVPTX won't work with the code nvopencc can handle (please see the log below). So are atomic intrinsics not supported or am I doing call in a wrong way? Thanks, - Dima. SOURCE ======== dmikushin at hp2:~> cat kernelgen_monitor.ll ; ModuleID =

Given 2 GEPs as follows, %tmp124 = getelementptr inbounds %struct.termbox* %termptr.1, i32 0, i32 5, !dbg !1051 ; <[2 x i16]*> [#uses=1] %tmp125 = getelementptr inbounds [2 x i16]* %tmp124, i64 0, i64 0, !dbg !1051 ; <i16*> [#uses=1] can I replace the 2nd one with %tmp126 = getelementptr inbounds %struct.termbox* %termptr.1, i32 0, i32 5, i64 0, i64 0 ; <i16*> When I try to

On Thu, Aug 20, 2015 at 7:17 PM, John McCall <rjmccall at apple.com> wrote: > > On Aug 20, 2015, at 5:19 PM, Evgenii Stepanov via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > Hi, > > > > There is a problem with the handling of alwaysinline functions in > > Clang: they are not always inlined. AFAIK, this may only happen when > > the caller is

Hello, it looks like I do have infinite loop in llc on linux/armv7 platform somewhere in llvm::SmallVectorImpl. Two backtraces obtained with 10 seconds delay are: 0x0099be14 in llvm::SmallVectorTemplateCommon<llvm::SDNode*>::setEnd (this=0x7ee90b38, P=0x5c06988) at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:103 103 void setEnd(T *P) { this->EndX = P; }

I'm getting this: /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: In member function `void llvm::SelectionDAGLowering::visitSetCC(llvm::User&, llvm::ISD::CondCode, llvm::ISD::CondCode, llvm::ISD::CondCode)': /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1107: error: ` UnsafeFPMath' undeclared (first use this function)

Hi Anton & Duncan, When I try to compile on Darwin now, I get this: $ /Volumes/Gir/devel/llvm/llvm-gcc-4.0.obj/gcc/xgcc <options> -o eh_alloc.o Assertion failed: (false && "Couldn't find the register class"), function getPhysicalRegisterRegClass, file /Volumes/Gir/devel/llvm/ llvm.src/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp, line 269.

TLDR: Heads up for out of tree backends - you're going to need to update your *DAGToDAGISel::Select method to unconditionally replace nodes directly instead of returning the desired replacement. So I'm working on fixing the undefined behaviour I described in llvm.org/PR26808. As part of this, we need to stop looking into deleted SDNodes to check if they were, in fact, deleted. A big place

On Mon, Dec 21, 2015 at 12:08 AM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Sun, Dec 20, 2015 at 5:57 PM, Johan Engelen <jbc.engelen at gmail.com> > wrote: > > > > Perhaps LLVM_ATTRIBUTE_ALWAYS_INLINE could be defined to "inline" if the > > compiler has no support for always_inline (currently it is set to > nothing in > > that

Dear LLVM, I'm trying to understand why the attached IR code works for x86_64 target and fails for nvptx64, because of unimplemented expand during the target lowering. Any ideas? Just change the target triple to x86_64-unknown-unknown, and the same IR code could we successfully codegen-ed for x86_64. Thanks, - Dima. dmikushin at dmikushin-desktop:~/Desktop$ gdb ~/sandbox/bin/llc GNU gdb

I believe this patch has broken a PPC app that I am tracking. Here is a reduced test case. Reproduce with llc -mattr=+Altivec -mcpu=g5. The backtrace looks like this: #0 0x9333ae42 in __kill () #1 0x9333ae34 in kill$UNIX2003 () #2 0x933ad23a in raise () #3 0x933b9679 in abort () #4 0x933ae3db in __assert_rtn () #5 0x0008bd8f in llvm::MVT::getVectorElementType (this=0xbfffdda4) at

On 2/24/11 10:39 AM, Arushi Aggarwal wrote: > Given 2 GEPs as follows, > > %tmp124 = getelementptr inbounds %struct.termbox* %termptr.1, i32 0, > i32 5, !dbg !1051 ; <[2 x i16]*> [#uses=1] > %tmp125 = getelementptr inbounds [2 x i16]* %tmp124, i64 0, i64 0, > !dbg !1051 ; <i16*> [#uses=1] > > can I replace the 2nd one with > > %tmp126 = getelementptr

Evan: I did not encounter this back trace before I committed the newest BuildVectorSDNode patch, which removed all class instance members and passes results back via reference parameters. -scooter On Tue, Feb 24, 2009 at 11:39 AM, Evan Cheng <evan.cheng at apple.com> wrote: > I believe this patch has broken a PPC app that I am tracking. Here is a > reduced test case. Reproduce

Evan: I work on reverting it, although, when I tried yesterday, it wasn't particularly clean (lots of rejected patches, presumably due to intervening commits.) Are you still getting the backtrace or is this just a case of incorrectly generated code? -scooter On Wed, Feb 25, 2009 at 10:09 AM, Evan Cheng <echeng at apple.com> wrote: > Things are still broken. Unfortunately llvm

Things are still broken. Unfortunately llvm test suite does not contain enough vector code to fully test this. Can you revert the patch first? Evan On Feb 24, 2009, at 7:14 PM, Scott Michel wrote: > Evan: > > I did not encounter this back trace before I committed the newest > BuildVectorSDNode patch, which removed all class instance members > and passes results back via