RetroSearch Browse

Tue Jul 14 17:00:39 PDT 2020 · https://lists.llvm.org/pipermail/llvm-dev/2020-July/143398.html

On 7/14/20 4:34 PM, Hal Finkel via llvm-dev wrote:
>
> On 7/14/20 11:28 AM, Fangqing Du wrote:
>> Thank you Hal and Stefan!
>>
>> Bug report is filed: https://bugs.llvm.org/show_bug.cgi?id=46717 
>> <https://bugs.llvm.org/show_bug.cgi?id=46717>
>>
>> And Stefan,
>> I think 'attributor' is a really nice pass, and can infer more 
>> precise and useful attributes, which may give more opportunitiesÂ for 
>> optimization.
>> But we shouldn't depend on 'attributor' to correct wrong function 
>> attributes, because we cannot run 'attributor' after every pass, right?
>
> Correct. Each pass must be correct on its own. We need to fix ipsccp.
>
I don't think that was ever questioned ;)

I think the comment about the Attributor was more to show that this behavior

is not the same there which is yet another good indicator this is a bug.

~ Johannes

> Â -Hal
>
>
>>
>> Thanks,
>> Fangqing
>>
>> On Sat, Jul 11, 2020 at 5:12 AM Hal Finkel <hfinkel at anl.gov 
>> <mailto:hfinkel at anl.gov>> wrote:
>>
>> Â Â Â  Hi, Fangqing,
>>
>> Â Â Â  Yes, this seems like a bug. Can you please file a bug report at
>> Â Â Â  https://bugs.llvm.org/ <https://bugs.llvm.org/> ? If you need
>> Â Â Â  someone else to do this on your behalf, please let us know.
>>
>> Â Â Â  Â -Hal
>>
>> Â Â Â  On 7/10/20 9:04 PM, Fangqing Du via llvm-dev wrote:
>>> Â Â Â  Hi all,
>>>
>>> Â Â Â  Let's see an example (from Alexandre Isoard) first:
>>> ****************************************************************************************
>>> Â Â Â  ; RUN: opt -ipsccp -deadargelim -licm -O2 -S < %s
>>>
>>> Â Â Â  @gÂ = internal global i32 0
>>>
>>> Â Â Â  ;Â FunctionÂ Attrs:Â argmemonly
>>> Â Â Â  define internal void @foo(i32* nonnull dereferenceable(4) %arg,
>>> Â Â Â  i32 %val)Â #0Â {
>>> Â Â Â  entry:
>>> Â Â Â  Â Â store i32 %val, i32* %arg
>>> Â Â Â  Â Â ret void
>>> Â Â Â  }
>>>
>>> Â Â Â  define i32 @bar(i32 %n)Â {
>>> Â Â Â  entry:
>>> Â Â Â  Â Â store i32 1, i32* @g
>>> Â Â Â  Â Â br label %loop
>>>
>>> Â Â Â  loop: ;Â predsÂ =Â %bb1,Â %bb
>>> Â Â Â  %iÂ =Â phi i32Â [ %i.inc, %loopÂ ],Â [ 0, %entryÂ ]
>>> Â Â Â  %g.valÂ =Â load i32, i32* @g
>>> Â Â Â  %g.incÂ =Â addÂ nuw i32 %g.val, 1
>>> Â Â Â  tailÂ call void @foo(i32* @g, i32 %g.inc)
>>> Â Â Â  %i.incÂ =Â addÂ nuw i32 %i, 1
>>> Â Â Â  %condÂ =Â icmpÂ eq i32 %i.inc, %n
>>> Â Â Â  Â Â br i1 %cond, label %exit, label %loop
>>>
>>> Â Â Â  exit: ;Â predsÂ =Â %bb1
>>> Â Â Â  Â Â ret i32 %g.val
>>> Â Â Â  }
>>>
>>> Â Â Â  declare void @llvm.assume(i1)
>>>
>>> Â Â Â  attributesÂ #0Â =Â { argmemonlyÂ }
>>> ****************************************************************************************
>>>
>>> Â Â Â  With opt cmd '-ipsccp -deadargelim -licm -O2', functionÂ @bar will
>>> Â Â Â  return constant value 1, instead of correct value %n. This is
>>> Â Â Â  crazy, right?
>>> Â Â Â  Let's see what happens here.
>>> Â Â Â  Due to pass 'ipsccp' replaced the argument of function '@foo'
>>> Â Â Â  with global variable '@g', but keeps attr 'argmemonly' there, so
>>> Â Â Â  pass 'licm' will hoist the load of '@g' before the loop (as the
>>> Â Â Â  value of @g isn't changed, but it is changed), and will cause
>>> Â Â Â  function return wrong constant value '1', instead of '%n' (the
>>> Â Â Â  correct value) , like following:
>>> ****************************************************************************************
>>>
>>> Â Â Â  ;Â FunctionÂ Attrs:Â nofreeÂ norecurseÂ nounwindÂ writeonly
>>> Â Â Â  define i32 @bar(i32 %n) local_unnamed_addr #0Â {
>>> Â Â Â  entry:
>>> Â Â Â  ret i32 1
>>> Â Â Â  }
>>>
>>> Â Â Â  attributesÂ #0Â =Â { nofree norecurse nounwind writeonlyÂ }
>>> ****************************************************************************************
>>>
>>>
>>> Â Â Â  And if remove the 'argmemonly' attribute, functionÂ @bar will
>>> Â Â Â  return the correct value:
>>> ****************************************************************************************
>>>
>>> Â Â Â  ;Â FunctionÂ Attrs:Â nofreeÂ norecurseÂ nounwind
>>> Â Â Â  define i32 @bar(i32 %n) local_unnamed_addr #0Â {
>>> Â Â Â  entry:
>>> Â Â Â  ret i32 %n
>>> Â Â Â  }
>>> ****************************************************************************************
>>>
>>>
>>> Â Â Â  So if function attribute 'argmemonly' on functionÂ @foo is
>>> Â Â Â  correct, then there's a bug in pass 'ipsccp'. When it replaces
>>> Â Â Â  the function local value with global variable, then it shoud
>>> Â Â Â  remember to remove this function attribute.
>>>
>>> Â Â Â  Thanks,
>>> Â Â Â  Fangqing
>>>
>>> Â Â Â  _______________________________________________
>>> Â Â Â  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 
>>> <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>
>> Â Â Â  -- Â Â Â  Hal Finkel
>> Â Â Â  Lead, Compiler Technology and Programming Languages
>> Â Â Â  Leadership Computing Facility
>> Â Â Â  Argonne National Laboratory
>>
>>
>> _______________________________________________
>> 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/20200714/fd2f1356/attachment-0001.html>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://lists.llvm.org/pipermail/llvm-dev/2020-July/143398.html below:

[llvm-dev] Bug in pass 'ipsccp' on function attribute 'argmemonly'?