similar to: [LLVMdev] -instcombine broken with fastcall

On Oct 5, 2008, at 10:55 PM, Arnaud Bergeron wrote: > I found this with LLVM 2.3 and reproduced with svn as of about thirty > minutes ago and they both fail in the same way. > > If you run this code through opt -instcombine Your input code has undefined behavior. You have to mark the callsite as fastcc also. -Chris

Hi all, I was playing around with LLVM 7 and I discovered something that seems to me to be a bug -- or at least something that I don't understand. Take the following valid simple program and run -instcombine on it declare i8* @malloc(i64) define void @caller() { entry: call void @callee() ret void } define fastcc void @callee() { entry: %malloccall = call i8* @malloc(i64 9) store

On Fri, 5 Oct 2007, Arnold Schwaighofer wrote: >> to me like llvm-gcc honors that. Certainly it should. > > This would imply one fastcc abi (callee pops args on return) to rule > them all? > That is only if fastcall translates to llvm fastcc of course. fastcall != fastcc. fastcall is a well defined convention on x86 that has very specific ABI requirements. fastcc, on the

On 5 Oct 2007, at 20:00, Dale Johannesen wrote: >>> I am not to sure on that. because that would make modules compiled >>> with the flag on incompatible with ones compiled without the flag >>> off >>> as stack behaviour would mismatch. >>> It would be no problem to make the behaviour dependent on the -tail- >>> call-opt flag. i am not sure

Two related questions. This is with LLVM 2.4 doing a JIT compile to x86-64. (I generate LLVM IR using an IRBuilder instance, compile/optimize, and then call getPointerToFunction() to get a "native" function pointer.) (1) My reading of various mailing list messages seems to indicate that a function marked as using the "fastcc" calling convention

On Oct 5, 2007, at 10:41 AM, Evan Cheng wrote: > > On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > >> Hi Evan, >> I incoporated the changes you request but to the following i have got >> a question: >> >>> Also, moving the option >>> there will allow us to change fastcc ABI (callee popping arguments) >>> only when this option is

On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > Hi Evan, > I incoporated the changes you request but to the following i have got > a question: > >> Also, moving the option >> there will allow us to change fastcc ABI (callee popping arguments) >> only when this option is on. See Chris' email: > > I am not to sure on that. because that would make

Albert Graef wrote: > Jeff Kuskin wrote: >> Correct? If not, how do I call a LLVM JIT-generated fastcc function >> from a function statically compiled by GCC? > > Well, you can always generate a little wrapper function with C calling > convention which just calls the fastcc function. > I use the fastcall convention all the time. LLVM-jitted code calling GCC-compile

Jeff Kuskin wrote: > Correct? If not, how do I call a LLVM JIT-generated fastcc function > from a function statically compiled by GCC? Well, you can always generate a little wrapper function with C calling convention which just calls the fastcc function. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at

Hi Arnold, Thanks for the patch. Some questions and commons: 1. Have you test it against the llvm test suite? Does it work if fp elimination optimization is turned off? 2. Please follow llvm coding convention and make sure every line fits in 80 columns. 3. enum NameDecorationStyle { None, StdCall, - FastCall + FastCall, + FastCC // the normal fastcc calling convention }; Why is

On 23 Feb 2013, at 00:26, John McCall <rjmccall at apple.com> wrote: > On Feb 20, 2013, at 7:52 PM, John McCall <rjmccall at apple.com> wrote: >> On Feb 20, 2013, at 7:49 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>> On Wed, Feb 20, 2013 at 06:30:53PM -0800, John McCall wrote: >>>> On Feb 20, 2013, at 6:24 PM, Richard Smith <richard at

Hi Evan, first off thanks to you and Chris for taking time. On 6 Sep 2007, at 00:57, Evan Cheng wrote: > We'd like to see tail call optimization to be similar to the target > independent lowering of ISD::CALL nodes. These are auto-generated > from ???CallingConv.td files. Some target specific details such as > function address register (ECX in your example) should be coded in

On Mon, Jun 19, 2017 at 12:06 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > Hi, > > 2017-06-19 8:45 GMT-07:00 Andrew Kelley via llvm-dev < > llvm-dev at lists.llvm.org>: > >> Greetings, >> >> I have a Zig implementation of ceil which is emitted into LLVM IR like >> this: >> >> ; Function Attrs: nobuiltin nounwind >> define

Hi, It looks like PDT.getRootNode() returns NULL for: define fastcc void @c974001__lengthy_calculation. 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { entry: br label %bb bb: br label %bb } Isn't it a bug in PostDominatorTree? Please note that this crashes: opt -postdomtree -debug dom_crash.bc I think this should be reported as a bug, -Jakub On Sep 3, 2009, at

Greetings, I have a Zig implementation of ceil which is emitted into LLVM IR like this: ; Function Attrs: nobuiltin nounwind define internal fastcc float @ceil(float) unnamed_addr #3 !dbg !644 { Entry: %x = alloca float, align 4 store float %0, float* %x call void @llvm.dbg.declare(metadata float* %x, metadata !649, metadata !494), !dbg !651 %1 = load float, float* %x, !dbg !652 %2 =

using `opt --print-after-all -O3` I see that EarlyCSE is interpreting the call to `ceil` and constant fold: *** IR Dump After Early CSE *** ; Function Attrs: nobuiltin nounwind define i1 @do_test() #2 { Entry: %0 = call fastcc float @ceil(float 0.000000e+00) #6 %1 = call fastcc float @ceil32(float 0.000000e+00) #6 %2 = fcmp fast oeq float 0.000000e+00, %1 ret i1 %2 } So just running `opt

Jakub Staszak wrote: > Hi, > > It looks like PDT.getRootNode() returns NULL for: > > define fastcc void @c974001__lengthy_calculation. > 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { > entry: > br label %bb > > bb: > br label %bb > } > > > Isn't it a bug in PostDominatorTree? > > Please note that this crashes: >

Hello, > If anybody has an idea of how to fix this (other than using another > version of gcc because I am sick of compiling), I would appreciate. I > can offer backtraces or shell access if anybody is interested, just > ask me what you need. This was fixed couple of months ago. Please consider using current svn top of tree, not 2.3 release. -- WBR, Anton Korobeynikov

2008/9/21 Anton Korobeynikov <asl at math.spbu.ru>: > Hello, > >> If anybody has an idea of how to fix this (other than using another >> version of gcc because I am sick of compiling), I would appreciate. I >> can offer backtraces or shell access if anybody is interested, just >> ask me what you need. > This was fixed couple of months ago. Please consider

Comments: CheckDAGForTailCallsAndFixThem - 1. for (SelectionDAG::allnodes_iterator BE = DAG.allnodes_begin(), + BI = prior(DAG.allnodes_end()); BI != BE; BI--) { Please use pre-decrement instead of post-decrement. 2. The function is slower than it should be. You are scanning all the nodes in the DAG twice. You should just examine DAG.getRoot() to make determine whether it's a