[llvm-dev] Why are generic dag combines run before target dag combines?
Thomas Lively via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 9 23:14:09 PDT 2020
Thanks, that makes sense. I'm experimenting with using ISD::SPLAT_VECTOR in
the WebAssembly backend, and setting that operation to be legal causes the
dag combiner to combine vector_insert_elts on undef vectors to
splat_vectors. Generally this is useful, but I have a very specific pattern
that this breaks because it is only correct if all the other lanes are
undef. I don't really want to disable the splat_vector combine, though. I
just want it to happen later. I guess one solution would be to add a hook
to disable the combine and then duplicate it as a target combine in a later
stage.
On Thu, Jul 9, 2020 at 7:28 PM Craig Topper <craig.topper at gmail.com> wrote:
> Probably because there's also constant folding and canonicalization
> transforms usually at the beginning of the generic DAG combine. In general
> you probably want target combines to run after that. Is it possible to do
> your combine from the generic combined form? The other option is to add a
> TLI hook to disable the transform. We've got a quite a lot of those.
>
> ~Craig
>
>
> On Thu, Jul 9, 2020 at 7:05 PM Thomas Lively via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi llvm-dev,
>>
>> I just tried to implement a target-specific dag combine to preempt a
>> generic dag combine, and I was surprised to see that it didn't work because
>> the generic dag combines are run first. Does anyone know the rationale for
>> running the generic dag combines first? I would have expected the target
>> dag combines to run first because they have more specific information about
>> what combines will be useful.
>>
>> Thanks,
>>
>> Thomas
>> _______________________________________________
>> 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/20200709/74e51027/attachment.html>
More information about the llvm-dev
mailing list