[PATCH] D92270: [ConstantFold] Fold more operations to poison

Mikael Holmén via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Nov 30 04:25:24 PST 2020


uabelho added a comment.

Hi,

I'm seeing a miscompile with this patch. I'm not very good at the semantic differences between undef and poison so I don't know really where it goes wrong.

Before Early CSE I see this in the input:

  entry:
    %cmp1 = icmp uge i16 1015, 16, !dbg !9
    %shr = lshr i16 -1, 1015
    %cmp2 = icmp ugt i16 2, %shr
    %or.cond = or i1 %cmp1, %cmp2, !dbg !10
    br i1 %or.cond, label %if.then3, label %if.else4, !dbg !10

This corresponds to the following C-code:

  int16_t y1 = 1022;
  uint16_t res1 = 0;
  if (y1 < 0)
    res1 = 0;
  else
    res1 = 1015;
  
  if ((res1 >= 16) || (2 > (65535u >> res1)))
    res2 = 42;
  else
    res2 = 1;

So in the C input, the right shift is guarded and won't be carried out if res1 is too large to avoid UB, but in the ll file the lshr is executed unconditionally.

Then after Early CSE I instead get

  entry:
    br i1 poison, label %if.then3, label %if.else4, !dbg !9

So I suppose, with this patch the lshr will result in poison, and that poison will then make both %cmp2 and %or.cond be poison. And then we don't know where to jump so res2 gets the wrong value.

I'm not very good at poison semantics, but it seems to me that either the input to ewarly cse is invalid, or the patch has broken the semantics of "or"?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92270/new/

https://reviews.llvm.org/D92270



More information about the cfe-commits mailing list