[llvm-commits] [llvm] r55085 - in /llvm/trunk: include/llvm/CodeGen/FastISel.h lib/CodeGen/SelectionDAG/FastISel.cpp lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp

[Chris Lattner]

On Aug 21, 2008, at 12:00 AM, Evan Cheng wrote:

>
> On Aug 20, 2008, at 7:20 PM, Chris Lattner wrote:
>
>>
>> On Aug 20, 2008, at 6:21 PM, Evan Cheng wrote:
>>
>>>>
>>>> How would converting a multiply into a shift benefit compile time?
>>>
>>> It doesn't. This would be a code quality optimization. We want to be
>>> fast but it doesn't mean generating poor code. :-) We can do some  
>>> dag
>>> combiner type optimizations if they are cheap.
>>
>> For now, it probably isn't worth it to do this sort of thing.
>
> We'll see. People want fast and reasonable code. On some targets
> multiplication is really slow so it might be worthwhile to do cheap
> optimizations. We're certainly not at a point where we should worry
> about this.

Unless multiply expands into larger code (which it does for some  
targets) we shouldn't worry about this.  If they care about  
performance, they shouldn't use -O0 ;-).  I agree that there are some  
fuzzy cases that may make it worth handling though.

>> in practice, what we'll want to do for GEPs is try to fold them into
>> loads and stores where possible.  This will produce smaller code and
>> is probably going to be more significant than mul -> shift for fast
>> compiles.
>
> Sure. We'll look at optimizations that require examining multiple
> instructions at a time. It's probably a good idea to keep these ideas
> as FIXME's and / or in README files. We're obviously not ready to
> tackle this either.

Yes, I'm not suggesting we tackle this until loads and stores are fast- 
isel-able and stuff generally works :)

-Chris