Displaying 12 results from an estimated 12 matches for "brenthwalker".
2011 Dec 14
2
[LLVMdev] Failure to optimize ? operator
...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 second...
2011 Dec 14
0
[LLVMdev] Failure to optimize ? operator
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 (the...
2011 Dec 13
4
[LLVMdev] Failure to optimize ? operator
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
2012 Mar 27
1
[LLVMdev] Compiling integer mod
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.
2012 Jan 12
1
[LLVMdev] Bogus warning?
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.
2011 Nov 04
2
[LLVMdev] Question on JIT optimizations
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
2012 Jan 25
1
[LLVMdev] Pointer aliasing
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
2012 Jan 23
2
[LLVMdev] Pointer aliasing
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.
2012 Jan 25
4
[LLVMdev] Pointer aliasing
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).
2012 Jan 24
2
[LLVMdev] Pointer aliasing
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;
2012 Mar 28
2
[LLVMdev] Suboptimal code due to excessive spilling
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
2012 Jan 24
4
[LLVMdev] Pointer aliasing
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