[llvm-commits] [RFC] Additions to TargetTransform for operation legality

[Nadav Rotem]

Hi Hal!

Thanks for working on this.  

On Oct 12, 2012, at 10:05 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> Nadav, et al.,
> 
> I'd like to start using the new TargetTransform interface in BBVectorize. The first step is to enable BBVectorize to understand what operations are likely to be efficiently supported by the target.

Great. I agree. 

> While that's a difficult question to answer generally, I think a reasonable proxy will be: operations that won't be expanded during legalization are probably supported efficiently.

I agree that checking if the operation is non-expandable is a good idea. You assume that operations which are custom lowered are efficient, which is a reasonable assumption to make.  I think that we can improve the accuracy of this question if we add target-specific white-lists and black-lists that the different targets can implement. Also, I think that we will need to add target-hooks. But we need to start simple, so I am happy with your approach. 

> I've attached a patch which implements two functions: allowsUnalignedMemoryAccesses (which is straightforward), and isPromotedOperationLegalOrCustom, and I'd like some feedback on whether this seems like the right way to go.
 
You should use the VectorTargetTransformInfo. We don't want to create a single mega TargetLowering-like interface. If the main users of this information are the BB-vectorizer and the Loop-Vectorizer, then we should place this info in VectorTargetTransform. 

Bob Wilson suggested that this interface will return the 'cost' of the instruction. This will allow us to compare the costs of the vectorized function before and after vectorization.  We may want to vectorize the function even if we found that one instruction is illegal (unlike gcc which aborts). It all depends on the ratio of good to bad instructions - or the cost.  I think that the cost needs to be calculated (also) according to the TypeLegalization decision. So, for example, if we scalarize a type, we can give it a cost of 8 which reflects (insert + op  + extract).  If we split a type we can give it the cost 2.  We many need an iterative routine to query getTypeConversion() because type legalization is done in multiple phases.  

> I've not really tested this function, but I'd like to know if you think this is the right kind of interface for this, and if the approach is about right. Quickly, isPromotedOperationLegalOrCustom first promotes the type as would be required during type legalization, converts the IR instruction opcode or intrinsic identifier into an ISD opcode, promotes the type based on operation-specific promotion, and then checks whether the resulting operation/type combination is marked Legal or Custom.

I prefer that we don't reimplement the day-builder, but at the moment I don't have a better idea. Can you refactor SelectionDAGBuilder;:visitIntrinsicCall before doing this ?  Maybe we can share some code there. Maybe we can create a table with mapping between intrinsics to ISDNodes.

I think that the interface of "isPromotedOperationLegalOrCustom" should be a single parameter - a pointer to the IR. 
The legalization code may want to walk up the IR and look around. For example, for shuffles, it may want to check if one of the operands is undef.
Also, you don't provide enough information to make a good decision. I want to be able to estimate the cost of zext_v8i8_to_v8i32. 

Thanks,
Nadav

> Thanks in advance,
> Hal
> 
> -- 
> Hal Finkel
> Postdoctoral Appointee
> Leadership Computing Facility
> Argonne National Laboratory
> <ttrans_oplegal.patch>