flip1995 updated this revision to Diff 342345.
flip1995 added a comment.
[MC] Untangle MCContext and MCObjectFileInfo
This untangles the MCContext and the MCObjectFileInfo. There is a circular
dependency between MCContext and MCObjectFileInfo. Currently this dependency
also exists during construc
flip1995 added a comment.
> The refactoring adding `Triple` to `MCContext::MCContext` [...] should be
> separate.
In order to make the `MCContext` construction independent from the
`MCObjectFileInfo`, passing the `Triple` to the `MCContext` is necessary
anyway. Moving it completely to the `MCC
shafik added inline comments.
Comment at: clang/lib/Parse/ParseStmtAsm.cpp:589
+ TheTarget->createMCObjectFileInfo(
+ /*PIC*/ false, Ctx));
+ Ctx.setObjectFileInfo(MOFI.get());
`/*PIC=*/false`
Comment at: llvm/tools/llvm-mca/llvm
shafik added inline comments.
Comment at: lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp:909
+ new llvm::MCContext(llvm::Triple(triple), asm_info_up.get(),
+ reg_info_up.get(), nullptr,
subtarget_info_up.get()));
if (!context_up)
--
MaskRay added a comment.
The `InitMCObjectFileInfo` refactoring is good, but I'll suggest
`initMCObjectFileInfo(MCContext &ctx, bool PIC, bool LargeCodeModel)` (change
the function name to `lowerCase`, and reorder MCContext before bool arguments).
The refactoring adding `Triple` to MCContext::M
flip1995 added a comment.
Thanks for the review! I already thought that I will have to split this up, so
I made the commits self contained so I'll do that. One question before I start:
Where should I split this? Should I only split out the RISC-V patch and leave
the changes that targets can def
MaskRay added a comment.
The refactoring part seems useful on its own. The controversial 4-byte
alignment part should be split.
Doesn't GNU as use 4 for most architectures as well? Why do you want to change
it?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews
jrtc27 added a comment.
Herald added a subscriber: JDevlieghere.
What's the benefit of less-aligned functions? Is that not more likely to get
poor performance due to cache line straddling of the first instruction?
Regardless, the functional change should be separated out from the refactoring.
flip1995 created this revision.
flip1995 added reviewers: MaskRay, rnk, asb.
Herald added subscribers: frasercrmck, dexonsmith, luismarques, apazos,
sameer.abuasal, s.egerton, Jim, jocewei, rupprecht, PkmX, the_o, brucehoult,
MartinMosbeck, rogfer01, atanasyan, edward-jones, zzheng, jrtc27, gbedw
