[llvm-bugs] [Bug 46229] New: X86 MachineVerifier error from TLS_base_addr64

[via llvm-bugs]

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

            Bug ID: 46229
           Summary: X86 MachineVerifier error from TLS_base_addr64
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: jyknight at google.com
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, spatel+llvm at rotateright.com

TLS access can occur within a call sequence, which ends up generating a
ADJCALLSTACK sequence nested within another ADJCALLSTACK sequence. Which, at
least according to the MachineVerifier, is illegal.

Run: `llc -verify-machineinstrs -relocation-model=pic -o - test.ll`

test.ll
=======
target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@TLS = internal thread_local global i64 zeroinitializer, align 8
declare void @bar(i64*)
define internal void @foo() {
  call void @bar(i64* @TLS)
  call void @bar(i64* @TLS)
  ret void
}
=======

Results in:
*** Bad machine code: FrameSetup is after another FrameSetup ***
- function:    foo
- basic block: %bb.0  (0x8e98c48)
- instruction: ADJCALLSTACKDOWN64 0, 0, 0, implicit-def $rsp, implicit-def
$eflags, implicit-def $ssp, implicit $rsp, implicit $ssp

*** Bad machine code: FrameDestroy is not after a FrameSetup ***
- function:    foo
- basic block: %bb.0  (0x8e98c48)
- instruction: ADJCALLSTACKUP64 0, 0, implicit-def dead $rsp, implicit-def dead
$eflags, implicit-def dead $ssp, implicit $rsp, implicit $ssp


The result of ISel is like this -- with the TLS access within the
call-sequence:
 ADJCALLSTACKDOWN64
 TLS_base_addr64
 ...
 CALL64pcrel32
 ADJCALLSTACKUP64

And then in expand-pseudos, the TLS_base_addr64 pseudo surrounds itself with
another set of ADJCALLSTACK.

So, you end up with:
 ADJCALLSTACKDOWN64
 ADJCALLSTACKDOWN64
 TLS_base_addr64
 ADJCALLSTACKUP64
 ...
 CALL64pcrel32
 ADJCALLSTACKUP64

-- 
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/20200607/6cfeb186/attachment.html>