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

[Dale Johannesen]

On Sep 22, 2008, at 10:48 AMPDT, Chris Lattner wrote:

> 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?

No.
(To be sure, every compiler IR starts out with the goal of keeping  
language-specific knowledge out of the BE and target-specific  
knowledge out of the FE, but I'm not sure any succeeds completely.   
ANDF might have.)

>>>> 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.

Actually neither readnone nor readonly does a good job of capturing  
the semantics of (say) log; we want something in between that means  
"reads rounding mode but not memory".  As discussed elsewhere.