[LLVMdev] Removing the separation between opt and codegen?

[Rotem, Nadav]

>>seems suboptimal. It would mean that 'opt' could no longer perform the same level of optimization as
>>'clang' with equivalent inputs. That being the case, I think that over time 'opt' would simply fall out of
>>use. My general question is this: What do we gain by keeping a strict separation between the
>>(mostly-target-independent) optimization layer and the codegen layer?

I was under the impression that opt would also be able to benefit from the added capabilities. After all, opt is just a driver, and can be taught to understand the 'march' 'mcpu' flags. 
I agree that it is important to allow opt to access the TLI for two reasons: 1. We use opt to test our code. 2. Vectorizers may want to service domain specific languages which may not necessarily use clang. 

>>I fear, however, that this leads to a system which is generally good, but not great on any particular
>> target. Furthermore, it is sometimes very difficult or impossible for the backends to undo bad 
>> decisions made by the target-independent optimization layer. 

Yes, but this is a general compiler problem. Early optimizations have no knowledge of how they affects later stages. For example, we don't consider register pressure when we inline a function. The problem is even more severe with vectorizing compilers. One problem that I mentioned in the past was that on 64bit systems, 32bit scalars are promoted into 64bit numbers. Later on, the vectorizer attempts to vectorize this value, but the problem is, that it is much more difficult to vectorize vectors of i64s. For example, array indices which were i32 values are now vectors of i64s, which can't be used for scatter/gather operations (which use i32 indices).

>> Nevertheless,  the most efficient and maintainable way to provide target information to the
>> optimization passes will be to provide that information directly from the backend code (and 
>> associated tablegen files).
>>I would like to hear other opinions on this.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.