[llvm-bugs] [Bug 31736] New: Combine consecutive fences & atomic-related optimisations

[via llvm-bugs]

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

            Bug ID: 31736
           Summary: Combine consecutive fences & atomic-related
                    optimisations
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: davide at freebsd.org
                CC: chandlerc at gmail.com, filcab at gmail.com,
                    hboehm at google.com, llvm-bugs at lists.llvm.org,
                    llvm-bugzilla at jfbastien.com, llvm-dev at redking.me.uk,
                    simon.f.whittaker at gmail.com
    Classification: Unclassified

The following function:

int tinkywinky(void) {
    __sync_synchronize();
      __sync_synchronize();__sync_synchronize();
      __sync_synchronize();__sync_synchronize();
      __sync_synchronize();__sync_synchronize();
      __sync_synchronize();__sync_synchronize();
      __sync_synchronize();__sync_synchronize();
      __sync_synchronize();__sync_synchronize();
      __sync_synchronize();__sync_synchronize();
      __sync_synchronize();
    return 15;
}

gets lowered into:

tinkywinky():                        # @tinkywinky()
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mov     eax, 15
        ret

by clang-3.9

and 

tinkywinky():
        mfence
        mov     eax, 15
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        mfence
        ret

by gcc-6.3 (interesting the different position of the `mov` in the final
relocatable.

This is because InstCombine/InstSimplify/* don't combine adjacent fences. The
real question here is if it's legal to do this (i.e. has no obvservable
behaviour). I had a quick chat about this with Chandler yesterday night and he
asked to open a bug & cc: some people so we can all discuss about this).

Probably it's worth starting a discussion in the standard (if there's not
already one) about the guarantees provided in this case (if any).

-- 
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/20170124/98a9ae34/attachment.html>