search for: brenthwalk

...l    %ebp leal    3(%ecx,%ecx,4), %eax        imull   %edx, %eax        leal 1(%eax,%ecx,2), %eax ret============================================== Brent On Wed, Dec 14, 2011 at 9:58 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Dec 13, 2011 at 5:59 AM, Brent Walker <brenthwalker at gmail.com> wrote: >> The following seemingly identical functions, get compiled to quite >> different machine code.  The first is correctly optimized (the >> computation of var y is nicely moved into the else branch of the "if" >> statement), which the secon...

On Tue, Dec 13, 2011 at 5:59 AM, Brent Walker <brenthwalker at gmail.com> wrote: > The following seemingly identical functions, get compiled to quite > different machine code.  The first is correctly optimized (the > computation of var y is nicely moved into the else branch of the "if" > statement), which the second one is not (th...

The following seemingly identical functions, get compiled to quite different machine code. The first is correctly optimized (the computation of var y is nicely moved into the else branch of the "if" statement), which the second one is not (the full computation of var y is always done). The output was produced using the demo page on llvm's web site (optimization level LTO). Can

For the simple C program below I show the output of clang and the output of the VS compiler (I am on windows). Maybe this is obvious to you, but is it really faster to do 2 multiplications, 3 movl instructions, 2 shifts, 1 add, and 1 substract than to do 1 mov, 1 cdq, and 1 idiv? I run into this while trying to understand why my code runs slower with llvm than a comparable program on windows.

For the following (reduced) program: bool f(double** x) { const double *const *const p = x; return !p; } Clang outputs the following warning: warning: initializing 'const double *const *const' with an expression of type 'double **' discards qualifiers in nested pointer types [-Wincompatible-pointer-types] const double *const *const p = x; I believe the code is correct.

Hi, If hope this is the right list to post a question like this. If not, my apologies -- please redirect me. Following the Kaledoscope example I am trying to write a simple JIT and compile my own small language using LLVM. Compilation happens using the C++ api by constructing a VM and emitting code using the api (just as the Kaledoscope example). The code in this setup will be optimized

Hi Duncan, you have misunderstood me I think. Of course in this case you have to reload the doubles since as you say the pointers may be aliasing each other. I just wrote it this way to show the kind of code one gets if one cannot specify that pointers do now alias -- not adding the __restrict__ to the function arguments gives the same code as in my example with the local variables (with or

Hi LLVMers, I would like to ask a question regarding aliasing. Suppose I have the following program: double f(double** p ) { double a,b,c; double * x = &a; double * y = &b; double * z = &c; *x = 1; *y = *x + 2; *z = *x + 3; return *x+*y+*z; } LLVM can tell that the three pointers do not alias each other so can perform the constant folding at compile time.

Thank you for your reply. The compromise you describe below, is it a compromise in the LLVM back end or in clang? I run into this while building a compiler for a small DSL language for which I generate functions that receive a context from which they extract a bunch of pointers to doubles from which inputs are passed to the function (I just used C/clang in my examples to illustrate the problem).

Hi Roel, the code you list below is precisely what I expect to get (of course the stores must happen but the constant folding should happen as well). It all looks very strange. LLVM is behaving as if the __restrict__ keyword was not used at all. Even more strange is the fact that for this function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z) { *x = 1.0;

Hi, I have run into the following strange behavior and wanted to ask for some advice. For the C program below, function sum() gets inlined in foo() but the code generated looks very suboptimal (the code is an extract from a larger program). Below I show the 32-bit x86 assembly as produced by the demo page on the llvm home page ("Output A"). As you can see from the assembly, after

Can you explain please why it works for this version of the function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z); What is different here? There are stores here as well. Brent On Wed, Jan 25, 2012 at 12:34 AM, Roel Jordans <r.jordans at tue.nl> wrote: > Hi Brent, > > I think this is a problem in the easy-cse transform. In this transform