[llvm-bugs] [Bug 37284] New: [IPRA] wrong code: optimizing with a function that is not truly local

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=37284

            Bug ID: 37284
           Summary: [IPRA] wrong code: optimizing with a function that is
                    not truly local
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: paulsson at linux.vnet.ibm.com
                CC: llvm-bugs at lists.llvm.org

When enabling IPRA on SystemZ on spec-2006/dealII, the benchmark crashes
immediately.

It seems that there is a 'begin_active_line' method defined in tria.h, that is
included and compiled in four source files. In tria.cc, this function does not
clobber %r3 (which is *this), and so the *this pointer is not moved into %r3
argument register before the second consecutive call to this method, by another
method in the same file.

The linker then uses another definition from one of the other object files,
which does actually clobber %r3, and the error occurs.

My first question is why those definitions are different in different files? If
the call-graph guaranteed a handling of leaf-functions before callers, they
should be identical, or?

On the other hand, I don't understand how IPRA would dare to make the
assumption about %r3 not being clobbered on a non-local function, not compiled
in the same translation unit at the same time. Anything else seems risky to me,
right?

In the module that has the actually used version (which clobbers %r3), I see
these function attributes: 'linkonce_odr dso_local' In tria.o I see 'weak_odr
dso_local', which is not quite the same, although nearly. Perhaps some
optimizer is confused here since linkonce indicate "merged with other globals
of the same name when linkage occurs", while dso_local is defined as "the
compiler may assume that a function or variable marked as dso_local will
resolve to a symbol within the same linkage unit". 

Still, I wonder how this attribute would come into play here, since neither the
RegUsageInfoCollector or RegUsageInfoPropagator even checks the function
attributes..??

Shold RegUsageInfoCollector check the Function attributes and abort in this
case? Or are the Function attributes confused? 

Side question: Is it perhaps the intent that IPRA should actually work on a
small function like this, perhaps by replicating it and making a local
definition with a similar name?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180428/5320271a/attachment.html>