similar to: [LLVMdev] missed optimizations

Nuno Lopes a écrit : > Hi, > > I have two questions about optimizations performed by llvm. > > Consider these simple functions: > int x(int b) { return b?4:6; } > int y() { return x(0); } > > int x2() { return 5; } > int y2() { return x2(); } > > the optimized bitcode (with clang + opt -std-compiler-opts) is: > define i32 @y(...) nounwind { > entry:

On Thu, Sep 4, 2008 at 8:39 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > > I have two questions about optimizations performed by llvm. > > Consider these simple functions: > int x(int b) { return b?4:6; } > int y() { return x(0); } > > int x2() { return 5; } > int y2() { return x2(); } > > the optimized bitcode (with clang + opt

Hi, As a follow up of this thread I've made a patch that implements a simple approach to propagate the function return values as described previously. It can transform e.g. the following program: define i32 @f(...) nounwind { (...) %cond = select i1 %tobool, i32 2, i32 3 ; <i32> [#uses=1] ret i32 %cond } define i32 @g(...) nounwind { entry: %call = call i32 (...)* @f() ;

Hi all, I had the following function that used function pointers with void arguments, typedef void (*FP)(); void foo() { printf("hello world from foo\n"); } int main() { FP fp; fp = foo; (*fp)(); } The corresponding bitcode, with no optimizations is target datalayout =

----- Mensagem encaminhada de MAILER-DAEMON at sapo.pt ----- Ok, thank you all for your explanations! I'll try to implement those improvements in the coming days. Thanks, Nuno ----- Original Message ----- >> Hi, >> >> I have two questions about optimizations performed by llvm. >> >> Consider these simple functions: >> int x(int b) { return b?4:6; }

Do you compile this as C? In C, unlike in C++, empty parenthesis do not mean "no arguments", they mean "no prototype", which is typically treated the same way as varargs in calling conventions. To declare function with no arguments do typedef void (*FP)(void); Eugene On Wed, Apr 21, 2010 at 10:22 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > Hi all, > >

> On 10/18/2016 5:06 AM, Nuno Lopes via llvm-dev wrote: >> Another use is, for example, to implement bit-fields: >> a.x = 2 >> becomes: >> %v = load %a >> %v2 = freeze %v ; %v could be uninitialized data (poison) >> %v3 = ... bitmasking... >> store %a, %v3 > > It seems like you're saying that an integer load which touches any >

Say I have the following code: main.c: void foo(char *, ...); void bar(int, ...); int main(void) { foo("foo", 1); bar(1, 2, 3, "bar"); return 0; } foobar.c: int printf(const char *, ...); void foo(const char *str, int i) { printf("%s: %d\n", str, i); } void bar(int i, int j, int k, const char *str) { printf("%s

Hi Eli, > That said, clang really should be turning int x2() { return x(0); } > into "define i32 @x2()" rather than "define i32 @x2(...)"; the > function isn't varargs, and marking it as such could lead to wrong > code for exotic calling conventions. I always understood that this is correct per C language specification. For functions that are internal (static),

Hello, Everyone > On this specific case, IIRC, MinGW chokes if asmprinter is not on the > list of components. This may be another consequence of the malfunctoning > of llvm-config/GenLibDeps.pl on MinGW/MSYS. This works for me without any problems on mingw32. What are the problems you're seeing? -- WBR, Anton Korobeynikov

Sure, but is anyone willing to mentor?  I don't have time.  I can advise, but only infrequently. Philip On 02/16/2018 03:47 PM, Davide Italiano wrote: > Yes, I agree with you this sounds like a great GSoC. > > On Fri, Feb 16, 2018 at 3:42 PM, Nuno Lopes via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Maybe we could list some of these as a GSoC project?

On Sat, Jun 27, 2015 at 2:16 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > At least in C/C++ that's UB, yes. So you cannot map every turing machine to a valid C/C++ program then. :) Also, does this mean that "daemon" programs that run continuously till they're killed by the OS (using a mechanism that is not visible in C) are effectively undefined? -- Sanjoy >

Hi Tim, Thank you for your answer. *We've fairly recently fixed a bug that looks very similar (r238680,which was well after 3.6)* If I wanted to back port that to 3.5 where should I look at? Where in the ARM backend the decision to relax an instruction is taken? *That's weird. Even with "-filetype=obj" (the bug only occurs whendirectly writing an object file)? Not that it

Hi, Building the following C code I get a call instruction that has no noreturn attribute, while the function itself does have it. void foo(void **b) { __builtin_longjmp(b, 1); } define void @_Z3fooPPv(i8** %b) noreturn nounwind uwtable { entry: %0 = bitcast i8** %b to i8* tail call void @llvm.eh.sjlj.longjmp(i8* %0)

SGTM On 02/17/2018 03:52 PM, Nuno Lopes wrote: > I can step in, if that's ok with you. > Nuno > > -----Original Message----- From: Philip Reames > Sent: Saturday, February 17, 2018 1:04 AM > To: Davide Italiano ; Nuno Lopes > Cc: llvm-dev > Subject: Re: [llvm-dev] Missing attribute inference cases > > Sure, but is anyone willing to mentor?  I don't have

I can step in, if that's ok with you. Nuno -----Original Message----- From: Philip Reames Sent: Saturday, February 17, 2018 1:04 AM To: Davide Italiano ; Nuno Lopes Cc: llvm-dev Subject: Re: [llvm-dev] Missing attribute inference cases Sure, but is anyone willing to mentor? I don't have time. I can advise, but only infrequently. Philip On 02/16/2018 03:47 PM, Davide Italiano wrote:

You can use CallInst::hasFnAttr(). It checks for attributes in the instruction and in the function decl. http://llvm.org/docs/doxygen/html/Instructions_8cpp_source.html#l00345 Nuno ----- Original Message ----- > Hi, > > Building the following C code I get a call instruction that has no > noreturn > attribute, while the function itself does have it. > > void foo(void **b)

Running -early-cse on declare void @rn() readnone nounwind define void @f() { entry: call void @rn() ret void } removes the call to @rn(). But @rn() could have had an infinite loop in it in which case @f() went from being a non-terminating program to an terminating no-op. Is this intentional? The only way I can see this transform being legal is if infinite loops are declared to have

On Tue, Sep 16, 2008 at 1:59 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > This kind of transformation isn't currently done by LLVM (note that here > this pass is only removing case statements. other transformations are not of > my responsibility :). > The patch is available at > http://web.ist.utl.pt/nuno.lopes/llvm_function_ret_infer.txt > I would love to

Maybe we could list some of these as a GSoC project? Seems like a self-contained task that can be simple as desired and as hard as the student wants it to be. Nuno -----Original Message----- From: Philip Reames via llvm-dev Sent: Friday, February 16, 2018 6:48 PM To: llvm-dev Subject: Re: [llvm-dev] Missing attribute inference cases On 02/16/2018 10:29 AM, Philip Reames via llvm-dev wrote: