llvm dev - Dec 2020 - Using a MachineInstruction Address

Hi, 
Is there a straight-forward way to obtain an arbitrary MachineInstruction
address and maintain it updated along the backend optimizations, even if it is
in the middle of a MachineBasicBlock?
I have an instruction that takes a relative address. E.g 

BB0: 
myInstruction BBN + 4*x 

BBN: 
... x instructions ... 
target_instruction <<=== it points to here. 

The issues I have are: 
1) I only see the ability to obtain basic-block addresses/labels, and these are
only updated in terminator instructions. So by change that basic block is
renamed/merged the value in myInstruction gets corrupt.
2) Even if I set-up the instruction at the top of a basic block, eventually the
BB gets merged, so just pointing to the BB label is not enough.

I do see MCSymbol, but I don't get it. It seems to be resolved during asm
printing.

Thanks, 


Diogo Sampaio 
Senior Compiler Engineer • Kalray 
dsampaio at kalrayinc.com • [ https://www.kalrayinc.com/ | www.kalrayinc.com ] 

[ https://www.kalrayinc.com/ |   ] 
	
The Processor at the Heart 
of Intelligent Systems 

Please consider the environment before printing this e-mail. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201202/1fde3b6a/attachment.html>

I have a somewhat similar scenario in a downstream back-end. You might try #2
and then call one of:
  /// Set this block to reflect that it potentially is the target of an indirect
branch.
  void setHasAddressTaken() { AddressTaken = true; }

  /// Test whether this block must have its label emitted.
  bool hasLabelMustBeEmitted() const { return LabelMustBeEmitted; }



________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Diogo
Sampaio via llvm-dev <llvm-dev at lists.llvm.org>
Sent: Tuesday, December 1, 2020 6:06 PM
To: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] Using a MachineInstruction Address

External email: Use caution opening links or attachments

Hi,
Is there a straight-forward way to obtain an arbitrary MachineInstruction
address and maintain it updated along the backend optimizations, even if it is
in the middle of a MachineBasicBlock?
I have an instruction that takes a relative address. E.g

BB0:
     myInstruction BBN + 4*x

BBN:
     ... x instructions ...
     target_instruction       <<=== it points to here.

The issues I have are:
1) I only see the ability to obtain basic-block addresses/labels, and these are
only updated in terminator instructions. So by change that basic block is
renamed/merged the value in myInstruction gets corrupt.
2) Even if I set-up the instruction at the top of a basic block, eventually the
BB gets merged, so just pointing to the BB label is not enough.

I do see MCSymbol, but I don't get it. It seems to be resolved during asm
printing.

Thanks,


Diogo Sampaio
Senior Compiler Engineer • Kalray
dsampaio at kalrayinc.com • www.kalrayinc.com<https://www.kalrayinc.com>

[Kalray logo]<https://www.kalrayinc.com>
The Processor at the Heart
of Intelligent Systems

Please consider the environment before printing this e-mail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201202/8927aabc/attachment.html>

On Wed, 2 Dec 2020 at 17:32, Diogo Sampaio via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Is there a straight-forward way to obtain an arbitrary MachineInstruction
address and maintain it updated along the backend optimizations, even if it is
in the middle of a MachineBasicBlock?
> I have an instruction that takes a relative address. E.g
I added a similar feature to AArch64 recently to handle jump-tables. I
think tracking both BB-start and offset is probably a non-starter, so
to take vocabulary from your example I implemented something like:

        myInstruction Ltmp0
        [...]
    BBN:
        ... x instructions ...
    Ltmp0:
        target_instruction

In this situation target_instruction is a Pseudo-instructrion that
gets expanded at the AsmPrinter stage into a label followed by the
real instruction. Both myInstruction and target_instruction would
share some kind of immediate operand saying which instance they are,
and the symbol generated would be coordinated by XYZFunctionInfo
(first user asks for a temporary symbol and records it there).

If target_instruction could actually be lots and lots of different
alternatives that you don't want to create pseudos for then you may be
able to arrange a bundle with a label-pseudo and the real instruction.
I just mention this so you don't abandon the idea entirely, I can give
more details if needed.

Cheers.

Tim.