Bin.Cheng wrote:
> I don't know the implementation of the option, so two questions:
> 1) When the repack is done during compilation?  Is new code
> manipulating data layout added
>     by frontend?  If yes, better to do it during optimization thus is
> can be on demanding?  This
>     looks like one case of data layout transformation.  Not sure if
> there is enough information
>     to do that in optimizer.

Yes it adds a runtime check at function entry and packs array slices which
have a non-unity step. Currently it uses a call to _gfortran_internal_pack,
however this could be inlined and use alloca rather than malloc for small 

It might be possible to check which parameters are used a lot (or benefit
from vectorization) and only pack those.

> 2) For now, does this option force array repacking unconditionally?  I
> think it won't be too hard
>     to model when such data layout transformation is beneficial by
> looking at loop (nest) accessing
>     the array and comparing against the overhead.

Yes, it ensures all slices are packed, but that isn't strictly necessary.

>> it be feasible in Fortran to version functions or loops if all arguments are 
>> contiguous slices?
> I think a cost model is still needed for function/loop versioning.

Absolutely. If you staticially know at the call that all slices are contiguous 
you could
compile a version of the function using the contiguous attribute and skip all 
checks. Such function versioning would require LTO to work well.


Reply via email to