[llvm-dev] Does middle-end pass need to consider some special type when doing optimization? Or letting back-end to revert the optimization accordingly?
Florian Hahn via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 14 06:38:19 PDT 2021
> On Apr 14, 2021, at 13:39, Luo, Yuanke <yuanke.luo at intel.com> wrote:
>
> Hi,
>
> I discussed with Florian for a solution at https://reviews.llvm.org/D99152 <https://reviews.llvm.org/D99152>. Florian suggest introducing a specific intrinsic to replace bitcast in front-end, and backend need extra effort to optimize or eliminate the intrinsic. This idea looks good to me. Here is my plan.
> specify x86_amx in LangRef and verify the IR. Patches were uploaded at https://reviews.llvm.org/D100032 <https://reviews.llvm.org/D100032> and https://reviews.llvm.org/D100472 <https://reviews.llvm.org/D100472>.
> Add llvm.x86.tile.cast intrinsic in LLVM.
> Optimize some of llvm.x86.tile.cast code as bitcast does, and transform llvm.x86.tile.cast to amx intrinsic if it can't be eliminated.
> After the above 3 items are finished, replace bitcast with llvm.x86.tile.cast in front-end when generate IR for amx builtin.
> After some time for stabilization, remove bitcast transform code from LLVM.
>
Thanks for the update, I think that’s a good step forward to more effectively hash out the specification for the x86_amx type. I think it clarifies the expected behavior, but it would be great if other people could also take a look.
Cheers,
Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210414/f14d6716/attachment.html>
More information about the llvm-dev
mailing list