-
Notifications
You must be signed in to change notification settings - Fork 14.4k
MC: Store MCRelaxableFragment MCInst out-of-line #147229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -869,7 +869,8 @@ bool MCAssembler::relaxInstruction(MCRelaxableFragment &F) { | |
// If this inst doesn't ever need relaxation, ignore it. This occurs when we | ||
// are intentionally pushing out inst fragments, or because we relaxed a | ||
// previous instruction to one that doesn't need relaxation. | ||
if (!getBackend().mayNeedRelaxation(F.getInst(), *F.getSubtargetInfo())) | ||
if (!getBackend().mayNeedRelaxation(F.getOpcode(), F.getOperands(), | ||
*F.getSubtargetInfo())) | ||
return false; | ||
|
||
bool DoRelax = false; | ||
|
@@ -881,6 +882,8 @@ bool MCAssembler::relaxInstruction(MCRelaxableFragment &F) { | |
|
||
++stats::RelaxedInstructions; | ||
|
||
// TODO Refactor relaxInstruction to accept MCRelaxableFragment and remove | ||
// `setInst`. | ||
MCInst Relaxed = F.getInst(); | ||
getBackend().relaxInstruction(Relaxed, *F.getSubtargetInfo()); | ||
Comment on lines
+885
to
888
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It would be great if we could turn one instruction in a relaxable fragment into two. This is commonly done on RISC-V, and we have to use pseudos right now (which get expanded into two instructions later), but being able to emit the two instructions directly would be a lot more helpful, especially if we want to do another step and relax one of those instructions again. This would be possible if we got access to the whole fragment, but I guess with this change it becomes impossible as the relaxable fragment can now only contain one instruction. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for mentioning the RISC-V requirements. Right now, I need to focus on stabilizing the generic representation, as it's currently quite inefficient. The |
||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it ok to always drop Flags? We might end up with a different encoding for the relaxed instruction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MCInst::setFlags is only called by X86 (mostly disassembly, the MCInstLower uses don't use MCRelaxableFragment) and SPIRV (not using MCRelaxableFragment). Added an assert (Inst.getFlags()==0).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
X86MCInstLower::Lower calls setFlags and with allowEnhancedRelaxation, these can end up in a relaxable fragment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right. I take back my previous comment.. Updated the description
I only noticed the case after adding the
getFlags() == 0
assertion... The #78545 case should probably switch to llvm-objdump -dr