llvm dev - Jul 2020 - Selection DAG chain question

Re: Do they really need to be chained with each other or anything else
Yes. For 2 reasons. Our architecture lowers udivmem into something with 1
producer and 2 consumers. Reason 1) neither the producers nor the consumers
must get reordered. Reason 2) one of the consumers might be missing (either
the div or mod consumer might not be present. Yet we need to keep the
consuming instruction with side effects. The only way to achieve is to add
it into the chain. Problem here: divmod does not have a chain.

I scanned other architectures, haven't found an example where somebody
creates a chain out of thin air. Do you know any?

On Thu, Jul 16, 2020 at 10:54 AM Tim Northover <t.p.northover at
gmail.com>
wrote:
> On Thu, 16 Jul 2020 at 16:44, Hendrik Greving via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > But then the new nodes are not chained with respect to other nodes, or
> not chained with respect to each other, in case there are several UDIVREM.
>
> Do they really need to be chained with each other or anything else?
> The case I know of is when they get lowered to a libcall. That libcall
> has effects that mean it needs a chain of some kind, but it doesn't
> really matter in any other way where in the basic block it happens.
>
> As long as it's after its inputs have been created and before its
> outputs are consumed, everything is fine. And that's handled by the
> normal value operands.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200716/f39ccf6c/attachment.html>

Chain doesn't guarantee that operations on parallel chains don't get
interleaved. So if you need them to be tightly connected together and
there's no data value flowing between them, then you probably want to look
at using Glue rather than Chain.

~Craig


On Thu, Jul 16, 2020 at 11:10 AM Hendrik Greving via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Re: Do they really need to be chained with each other or anything else
> Yes. For 2 reasons. Our architecture lowers udivmem into something with 1
> producer and 2 consumers. Reason 1) neither the producers nor the consumers
> must get reordered. Reason 2) one of the consumers might be missing (either
> the div or mod consumer might not be present. Yet we need to keep the
> consuming instruction with side effects. The only way to achieve is to add
> it into the chain. Problem here: divmod does not have a chain.
>
> I scanned other architectures, haven't found an example where somebody
> creates a chain out of thin air. Do you know any?
>
> On Thu, Jul 16, 2020 at 10:54 AM Tim Northover <t.p.northover at
gmail.com>
> wrote:
>
>> On Thu, 16 Jul 2020 at 16:44, Hendrik Greving via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > But then the new nodes are not chained with respect to other
nodes, or
>> not chained with respect to each other, in case there are several
UDIVREM.
>>
>> Do they really need to be chained with each other or anything else?
>> The case I know of is when they get lowered to a libcall. That libcall
>> has effects that mean it needs a chain of some kind, but it doesn't
>> really matter in any other way where in the basic block it happens.
>>
>> As long as it's after its inputs have been created and before its
>> outputs are consumed, everything is fine. And that's handled by the
>> normal value operands.
>>
>> Cheers.
>>
>> Tim.
>>
> _______________________________________________
> 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/20200716/d9366262/attachment.html>

> On Jul 16, 2020, at 14:10, Hendrik Greving via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I scanned other architectures, haven't found an example where somebody
creates a chain out of thin air. Do you know any?

This is the case for all operations expanded as library calls. The call sequence
involves a chain. One of the AMDGPU fdiv expansions also introduces a side
effecting mode switch with a chain

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200716/3d2f8908/attachment.html>

> Chain doesn't guarantee that operations on parallel chains don't
get
interleaved

This would be a sequential chain...
> This is the case for all operations expanded as library calls
I think their originating node already has a chain (i.e. mem operand or
side effect in llvm-ir). My case is a arithmetic node without ordering
constraints (divrem) getting lowered into sth that _does_ have ordering
constraints. I first thought it is very straight forward, turns out it is
not a common case. My current WA will be to code prepare into intrinsics
with side-effects. I was wondering if that's really necessary..

Thanks for the input

On Thu, Jul 16, 2020 at 11:21 AM Matt Arsenault <arsenm2 at gmail.com>
wrote:
>
>
> On Jul 16, 2020, at 14:10, Hendrik Greving via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> I scanned other architectures, haven't found an example where somebody
> creates a chain out of thin air. Do you know any?
>
>
>
> This is the case for all operations expanded as library calls. The call
> sequence involves a chain. One of the AMDGPU fdiv expansions also
> introduces a side effecting mode switch with a chain
>
> -Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200716/8fb7fe99/attachment.html>