[llvm-commits] [llvm] r55781 - /llvm/trunk/lib/Transforms/Scalar/SimplifyLibCalls.cpp

[Chris Lattner]

On Sep 22, 2008, at 10:39 AM, Dale Johannesen wrote:
>> On Sep 4, 2008, at 11:30 AM, Dale Johannesen wrote:
>>> Author: johannes
>>> Date: Thu Sep  4 13:30:46 2008
>>> New Revision: 55781
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=55781&view=rev
>>> Log:
>>> Add intrinsic forms of pow and exp2.  The non-intrinsic
>>> forms remain to handle older IR files, but will go away soon.
>>
>> You want to remove handling of "powf" and only handle  
>> "llvm.pow.f32"?  Why?
>>
>> -Chris
>
> Because I don't think the BE should be sensitive to the source  
> language.

You don't think that LLVM should allow source-language-specific passes?

>>> That said, I think it is useful to distinguish between
>>> SimplifyLibcalls (SLC) and the rest of the compiler.
>>
>> Yes, SLC is specific to code that is using the standard C library.   
>> If you were writing a compiler for some language which had 'sin'  
>> mean something unusual, you'd just not run it.
>
> I don't think this makes sense.  What about languages that have some  
> of the standard C functions but not all of them?

This doesn't have anything to do with the backend knowing about source  
language: we already have this problem with GCC and C.  GCC supports - 
fno-builtin-foo.  We need a better way to model this, and that way may  
be to add intrinsics for everything that the optimizer looks at, but  
there are other options.

> This code should be language-independent, with any semantic  
> information (such as errno usage) encoded in the intrinisic; then  
> the BE can apply semantics appropriately.   (This, rarely enough, is  
> a case where gcc got the design right.)

I agree that the IR should capture errno assumptions/behavior.  For  
more of these functions, that can be done with readnone/readonly.

-Chris