llvm dev - Nov 2010 - [LLVMdev] C Backend's future

Chris Lattner <clattner at apple.com> writes:
> On Nov 5, 2010, at 7:11 AM, Kirk Kelsey wrote:
>
>> I'm wondering what the longer term plans are for the C Backend. I
>> understand it's not actively developed, even deprecated. What
I'm not
>> clear about is whether it's something that is viewed as non-vital
and
>> should just as well go away, or if it's just a low
>> priority. Basically: it's not improving, but is it likely to
>> disappear?
>
> I don't know of anyone actively working on it, and that means it
isn't likely to improve anytime soon.
I have quite a few patches for it queued up.  Vector code is a problem
since the C backend currently generates aligned vector loads of
unaligned data.
> In short, I don't see a compelling reason to rip it out anytime soon.
> If it ends up being completely broken for simple programs, it might
> make sense to remove in the future.
There's a big reason to keep it.  It's a godsend when trying to bugpoint
something where no working llc is available.  I've used it quite a lot
during AVX development, for example.  It's useful for developing any
new target.

                             -Dave

Hi Dave,
>>> I'm wondering what the longer term plans are for the C Backend.
I
>>> understand it's not actively developed, even deprecated. What
I'm not
>>> clear about is whether it's something that is viewed as
non-vital and
>>> should just as well go away, or if it's just a low
>>> priority. Basically: it's not improving, but is it likely to
>>> disappear?
>>
>> I don't know of anyone actively working on it, and that means it
isn't likely to improve anytime soon.
>
> I have quite a few patches for it queued up.  Vector code is a problem
> since the C backend currently generates aligned vector loads of
> unaligned data.
>
>> In short, I don't see a compelling reason to rip it out anytime
soon.
>> If it ends up being completely broken for simple programs, it might
>> make sense to remove in the future.
>
> There's a big reason to keep it.  It's a godsend when trying to
bugpoint
> something where no working llc is available.  I've used it quite a lot
> during AVX development, for example.  It's useful for developing any
> new target.
an alternative is to make the interpreter more powerful and have bugpoint
use it rather than the C backend.

Ciao,

Duncan.

In http://llvm.org/docs/tutorial/LangImpl4.html#jit there's an example that
optimizes calls to functions without side effects. Specifically,

ready> extern sin(x);
ready> extern cos(x);
ready> def foo(x) sin(x)*sin(x) + cos(x)*cos(x);
Read function definition:
define double @foo(double %x) {
entry:
        %calltmp = call double @sin(double %x)
        %multmp = fmul double %calltmp, %calltmp
        %calltmp2 = call double @cos(double %x)
        %multmp4 = fmul double %calltmp2, %calltmp2
        %addtmp = fadd double %multmp, %multmp4
        ret double %addtmp
}

I find that when I run the code, the calls to sin and cos aren't optimized
and, instead, I end up with:

define double @foo(double %x) {
entry:
  %calltmp = call double @sin(double %x)
  %calltmp1 = call double @sin(double %x)
  %multmp = fmul double %calltmp, %calltmp1
  %calltmp2 = call double @cos(double %x)
  %calltmp3 = call double @cos(double %x)
  %multmp4 = fmul double %calltmp2, %calltmp3
  %addtmp = fadd double %multmp, %multmp4
  ret double %addtmp
}

How do you tell LLVM if a function has side effects or not?

Cheers!

- Rob

Hi Rob,

You need to set attribute ReadOnly on the sin / cos functions, using
Function::addFnAttr(Attribute) for example.

Best regards,
--
Arnaud de Grandmaison

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Rob Pieke
Sent: Monday, November 15, 2010 11:41 AM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] Optimization of calls to functions without side effects (from
Kaleidoscope example)

In http://llvm.org/docs/tutorial/LangImpl4.html#jit there's an example that
optimizes calls to functions without side effects. Specifically,

ready> extern sin(x);
ready> extern cos(x);
ready> def foo(x) sin(x)*sin(x) + cos(x)*cos(x);
Read function definition:
define double @foo(double %x) {
entry:
        %calltmp = call double @sin(double %x)
        %multmp = fmul double %calltmp, %calltmp
        %calltmp2 = call double @cos(double %x)
        %multmp4 = fmul double %calltmp2, %calltmp2
        %addtmp = fadd double %multmp, %multmp4
        ret double %addtmp
}

I find that when I run the code, the calls to sin and cos aren't optimized
and, instead, I end up with:

define double @foo(double %x) {
entry:
  %calltmp = call double @sin(double %x)
  %calltmp1 = call double @sin(double %x)
  %multmp = fmul double %calltmp, %calltmp1
  %calltmp2 = call double @cos(double %x)
  %calltmp3 = call double @cos(double %x)
  %multmp4 = fmul double %calltmp2, %calltmp3
  %addtmp = fadd double %multmp, %multmp4
  ret double %addtmp
}

How do you tell LLVM if a function has side effects or not?

Cheers!

- Rob


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Duncan Sands <baldrick at free.fr> writes:
>> There's a big reason to keep it.  It's a godsend when trying to
bugpoint
>> something where no working llc is available.  I've used it quite a
lot
>> during AVX development, for example.  It's useful for developing
any
>> new target.
>
> an alternative is to make the interpreter more powerful and have bugpoint
> use it rather than the C backend.
That would actually be better.  I've never tried the interpreter.  Do
you have a sense of what's needed to make it more powerful?

                                      -Dave