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 slices. 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 runtime checks. Such function versioning would require LTO to work well. Wilco
