[clang] [llvm] [MC] Remove UseAssemblerInfoForParsing (PR #91082)

Fangrui Song via llvm-commits llvm-commits at lists.llvm.org
Tue May 14 16:09:22 PDT 2024


MaskRay wrote:

> > Thanks for the additional context. My main concern is that we're undoing the consensus of [reviews.llvm.org/D45164](https://reviews.llvm.org/D45164) which if I've understood the comments properly was "There is a reasonable expectation that compiled (not assembled) code should be identical, or at least as close to the assembly output.
> > I'm not hugely concerned about that personally as I don't think there are any written guarantees and I come from a background of a toolchain that didn't come close to that (assembler output was disassembled from object file), however there were some strong opinions on the original change.
> > Do we have any strong opinions from the other reviewers?
> > If there is a RFC I suggest that it would be entitled something like "[RFC] Clang assembly/object equivalence for files with inline assembly". If it is worded in such a way that this is needed for the kernel and we want to check for community input then if there is no response then we can go ahead.
> 
> Thanks for the suggestion. I created [discourse.llvm.org/t/rfc-clang-assembly-object-equivalence-for-files-with-inline-assembly/78841](https://discourse.llvm.org/t/rfc-clang-assembly-object-equivalence-for-files-with-inline-assembly/78841)

So far there has only been one reply from @efriedma-quic . Shall we go ahead?

> I care less about error messages than outright miscompiles.

We don't have miscompiles, just the difference in whether a `.if` construct can be assembled.

https://github.com/llvm/llvm-project/pull/91082


More information about the llvm-commits mailing list