[llvm-dev] How to prevent llvm's default optimization

[Craig Topper via llvm-dev]

This is likely more of a canonicalization than an optimization. This is
done so that if you got the add followed by mul input or the mul followed
by add input they would be canonicalized to the same sequence. Maybe not
the optimal sequence but at least the same. I didn't check, but I suspect
this is happening in InstCombine in the middle end.

~Craig


On Mon, Jun 29, 2020 at 8:37 PM Ben Shi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi, James,
>
> Thanks for your reply.
>
> I do not think it is always true, that "mul then add" is faster than "add
> then mul".
>
> For example,
>
> A small immediate can be directly encoded in the instruction, but it
> becomes a larger one after a multiplication, which has to be loaded from
> the constant pool (extra memory access).
>
> So I wonder, is it possile to prevent it, via changes to the config of the
> base class TargetLowering，than writing special custom C++ code.
>
>
> Ben
>
>
>
>
>
>
>
> At 2020-06-30 07:46:41, "James Courtier-Dutton" <james.dutton at gmail.com> wrote:
> >Hi Ben,
> >
> >Why do you want to stop it?
> >"mul then add" is faster than "add then mul".
> >The result is the same in both cases.
> >
> >On Mon, 29 Jun 2020 at 22:11, Ben Shi via llvm-dev
> ><llvm-dev at lists.llvm.org> wrote:
> >>
> >> Hello,
> >> I have an instruction pattern like
> >>   %2 = add i32 %0, 25
> >>   %3 = mul i32 %2, 525
> >>
> >> and llvm will optimize it to
> >> %2 = mul i32 %0, 525
> >> %3 = add i32 %2, 12525
> >>
> >> how to prevent it?
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200629/f312c917/attachment.html>