llvm dev - Sep 2014 - [LLVMdev] Use of custom operations after DAG legalization

I've been working on a backend for a 16-bit microcontroller and I've
just updated my base from LLVM 3.4 to LLVM 3.5.0. This threw up a regression
failure in my test suite, and having tracked down the cause, I'm now
confused about the DAG legalization and optimization process which I thought I
understood. I'd be really grateful for advice on whether I've
misunderstood how legalization works.

The target doesn't support MUL but does support i8 and i16 UMUL_LOHI and
SMUL_LOHI. I custom lower i16 MUL because it's possible to use i8 UMUL_LOHI
if the operands meet certain criteria. If this isn't possible, my
custom-lowering returns SDValue() and so falls back onto the default expansion,
which is to generate i16 SMUL_LOHI and use only the low result. This worked fine
when I was using 3.4 but in 3.5.0, the DAG Combiner replaces a SMUL_LOHI whose
high result is unused with a MUL. I traced this to r199678 in which the DAG
Combiner was changed specifically to allow this replacement when MUL is either
Legal or Custom. In 3.4, it was only permitted if MUL was Legal. For my target,
the 3.5.0 behaviour isn't acceptable because the subsequent instruction
selection will fail as i16 MUL isn't legal. I could work around this by not
falling back onto the default expansion for i16 MUL, and instead lowering to a
target-specific SMUL_LOHI but I'd rather not duplicate the existing
expansion code if possible.

This got me wondering why it's ever permitted for the DAG Combiner, when
running post-legalization, to combine to an operation that requires custom
lowering. I'd believed that after legalization, all operations were Legal
and that none were permitted to be Custom. I see several places in DAGCombine
where nodes are combined, post-legalization, to Legal or Custom operations but I
can also see other places where only Legal operations are permitted. Is this
intentional?

On 26 Sep 2014, at 11:34, Steve Montgomery <stephen.montgomery3 at
btinternet.com> wrote:
> This got me wondering why it's ever permitted for the DAG Combiner,
when running post-legalization, to combine to an operation that requires custom
lowering. I'd believed that after legalization, all operations were Legal
and that none were permitted to be Custom. I see several places in DAGCombine
where nodes are combined, post-legalization, to Legal or Custom operations but I
can also see other places where only Legal operations are permitted. Is this
intentional?
I've hit numerous similar issues with SelectionDAG.  They're all
difficult to debug because the typical behaviour is an infinite loop, where the
back end replaces something generic with something that works for the
architecture and then SelectionDAG decides to replace this with the original
generic thing.  One example is that our architecture supported unaligned loads
and stores with some pointer types, but not others.

David

I'm glad I'm not the only one having issues in this area.

Is anyone able to offer an opinion or answer to the original question, namely:
is it permitted for the DAG Combiner to introduce anything other then legal
operations when it is running post-legalization?

It seems counter-intuitive to me that illegal operations are be introduced at
this stage. However, I see that some backends use Custom to permit a
custom-lowering of an operation that is actually natively supported, an example
being Mips i32 SELECT.

Steve Montgomery

On 26 Sep 2014, at 16:44, David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:
> On 26 Sep 2014, at 11:34, Steve Montgomery <stephen.montgomery3 at
btinternet.com> wrote:
> 
>> This got me wondering why it's ever permitted for the DAG Combiner,
when running post-legalization, to combine to an operation that requires custom
lowering. I'd believed that after legalization, all operations were Legal
and that none were permitted to be Custom. I see several places in DAGCombine
where nodes are combined, post-legalization, to Legal or Custom operations but I
can also see other places where only Legal operations are permitted. Is this
intentional?
> 
> I've hit numerous similar issues with SelectionDAG.  They're all
difficult to debug because the typical behaviour is an infinite loop, where the
back end replaces something generic with something that works for the
architecture and then SelectionDAG decides to replace this with the original
generic thing.  One example is that our architecture supported unaligned loads
and stores with some pointer types, but not others.
> 
> David
>