[llvm-dev] Unreferenced BlockAddress broke IR compilation?

[Zhang via llvm-dev]

Seems like it's an issue related to some state caching.


I tried to comment out MMIAddrLabelMap::getAddrLabelSymbolToEmit  in MachineModuleInfo.cpp 's cache related code. (The one related to loading from AddrLabelSymbols) and the emitted assembly seems to be correct, at least the branch table is correct.


Arthur can you double check this? This was reproducible even for functions without a dangling BasicBlock in my IR.


Zhang
 
 
------------------ Original ------------------
From:  "llvm-dev"<llvm-dev at lists.llvm.org>;
Date:  Mon, Apr 12, 2021 03:15 PM
To:  "Arthur Eubanks"<aeubanks at google.com>; 
Cc:  "llvm-dev"<llvm-dev at lists.llvm.org>; 
Subject:  Re: [llvm-dev] Unreferenced BlockAddress broke IR compilation?

 

Hi:
Unfortunately main is beyond our use-case. Is there any suggestion on how to work around this bug?
Also, found a new case where even non-dead basicblocks could reproduce the same issue, is there any suggestion on how can I debug this?


Zhang
 
 
------------------ Original ------------------
From:  "Arthur Eubanks"<aeubanks at google.com>;
Date:  Mon, Apr 12, 2021 11:57 AM
To:  "Zhang"<admin at mayuyu.io>; 
Cc:  "llvm-dev"<llvm-dev at lists.llvm.org>; 
Subject:  Re: [llvm-dev] Unreferenced BlockAddress broke IR compilation?

 

Does https://reviews.llvm.org/rG90af134473331095adcf2c7e4a511ac35d9f2f4a help?

On Sun, Apr 11, 2021 at 8:41 PM Zhang via llvm-dev <llvm-dev at lists.llvm.org> wrote:

Hi:
I'm currently using 176249bd @ release/11.x for a downstream project that contains two passes.
The first pass randomly introduces DeadBasicBlocks (BasicBlocks that are not branched to in any way).
The second pass creates BlockAddress of all BasicBlocks in a function, put them into a GlobalVariable and patch br instructions to GEP+Load+indibr instructions.


When the first pass didn't create deadBasicBlock, the transformed IR fully works as intended, however if deadbasicblock is introduced, all elements in the GV created in the second pass references to the same address in the compiled object file.


Not sure if this is a bug on LLVM side or not





_______________________________________________
 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/20210412/5f11652c/attachment.html>