[llvm-dev] [cfe-dev] CFG simplification question, and preservation of branching in the original code

[Finkel, Hal J. via llvm-dev]

On 10/4/19 5:46 AM, Joan Lluch via llvm-dev wrote:
Hi all,

As a continuation of this thread, I was about to fill a bug report requesting the modification of DAGTypeLegalizer::ExpandIntRes_SIGN_EXTEND, in order to avoid the creation of Shifts for targets with no native support. For example by generating a ‘select' equivalent to  a<0 ? -1 : 0 instead of an arithmetic shift right. For targets with no multiple shifts or word extension instructions, the select is much cheaper.

However, I found that the early InstCombine pass spoils such optimisation by creating shifts on their own as a transform of (supposedly) equivalent code.

...

I strongly suggest the above gets fixed. HOWEVER, even after the DAG combiner is fixed, the issues will remain due to InstCombine doing essentially the same thing much earlier. Consider code like this:

int test0( int a )
{
  return a<0 ? -1 : 0;
}

int test1( int a )
{
  return a<0 ? 1 : 0;
}

int test2( int a )
{
  return a<0 ? 2 : 0;
}

int test3( int a )
{
  return a<0 ? 3 : 0;
}

In all cases, InstCombine converts the above into Shifts, right into the IR, which the backend can’t do anything about.


Why not? It seems like we could pattern match the shifts back into selects/branches?

 -Hal


...






_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191004/28d09ebb/attachment.html>