Assigning custom information to IR instruction and passing it to its correspondent in Selection DAG

Project Infrastructure LLVM Dev List Archives
1

Hello,

I’m looking for the best approach which would allow for marking given LLVM IR instruction during IR custom pass and later utilizing that information during DAG Instruction Selection in order to match given pattern based on this marking.

I’m wondering if marking IR instruction utilizing Metadata is good idea.

But how later pass that information to DAG and appropriately mark in DAGBuilder SDNode, which represents the earlier marked instruction in IR?

Any suggestion how to implement the most efficiently?

I’m expecting there are already similar solutions – maybe someone would be able to indicate the exact example?

Thanks in advance,

Przemek

2

Hi,
as I wrote in mu previous post I wanted to somehow mark one IR instruction (in this particular case it would be ‘load’) during dedicated pass, which will set the marking based on neighboring instructions. Next I wanted to somehow to convey this marking from ‘load’ IR instruction to ‘load’ SDNode in order to use it during DAG Instruction Selection - information stored in this marking would ‘enable’ or ‘disable’ particular pattern… I was thinking about usage metadata for it, but I didn’t get any feedback.

So now I’m wondering if solution with metadata is the best one or it maybe it doesn’t make any sense an something else would be better.

I don’t have big experience with metadata, but what I’ve read it would allow for customizing IR instruction without modifying the instruction. Or maybe I’m unnecessarily thinking about metadata, because ‘load’ instruction has already some fields which could be used for storing ‘flags’, which might represent any custom information. Obviously I don’t want to modify ‘load’.

Any suggestions?

Thanks,
Przemek

3

In general metadata aren’t recommended for carrying semantically important information as they can be dropped at any time.

What about using a target specific intrinsic? Your pass could convert the instructions to your intrinsic that you can then easily match in SelectionDAG.

4

Thanks Mehdi for the suggestion.

I want to customize handling of ‘load’ instruction during processing DAG, but on IR level I want the ‘load’ to be treated in different passes as common load. So I’m afraid that replacing ‘load’ with Intrinsic would cause different handling it comparing to LoadInst.
I’ve found that in the DAGBuilder metadata information connected with LoadInst instruction is utilized:
bool isInvariant = I.getMetadata(LLVMContext::MD_invariant_load) != nullptr;

Is this metadata somehow protected against dropping - as you mentioned?

Thanks,
Przemek

5

Thanks Mehdi for the suggestion.

I want to customize handling of ‘load’ instruction during processing DAG, but on IR level I want the ‘load’ to be treated in different passes as common load. So I’m afraid that replacing ‘load’ with Intrinsic would cause different handling it comparing to LoadInst.

Yes this is the kind of replacement you would do after the general optimizations.
If you need to attach this information when you create the IR (from the front-end directly for example) then intrinsics or metadatas are the only two ways I know of.
Depending on what is it exactly that you are trying to model, function attributes can be used but they would apply to the whole function (or specific arguments). It may also be possible to use an intrinsic to mark the pointer itself instead of the instructions manipulating it, again it depends on what you are modelling.

I’ve found that in the DAGBuilder metadata information connected with LoadInst instruction is utilized:
bool isInvariant = I.getMetadata(LLVMContext::MD_invariant_load) != nullptr;

Is this metadata somehow protected against dropping - as you mentioned?

Nothing is protected as far as I know, the design is that it should always be legal to drop a metadata.
I don’t know what the invariant_load information is used for at the place you looked at, but I assume that I can take the IR, strip it out of the “invariant_load” metadata from the loads, and optimizations/codegen should still be correct. If your use-case fits in this model then metadata is likely a good starting point.

Best,

6

I want to customize handling of ‘load’ instruction during processing DAG, but on IR level I want the ‘load’ to be treated in different passes as common load. So I’m afraid that replacing ‘load’ with Intrinsic would cause different handling it comparing to LoadInst.

Yes this is the kind of replacement you would do after the general optimizations.
If you need to attach this information when you create the IR (from the front-end directly for example) then intrinsics or metadatas are the only two ways I know of.
Depending on what is it exactly that you are trying to model, function attributes can be used but they would apply to the whole function (or specific arguments). It may also be possible to use an intrinsic to mark the pointer itself instead of the instructions manipulating it, again it depends on what you are modelling.

So you are suggesting to replace something like:
%ptr = alloca i32
%val = load i32, i32* %ptr

with

%ptr = alloca i32
%custom.ptr = call i32* @llvm.customhandling(i32* %ptr)
%val = load i32, i32* %custom.ptr

?

I’ve found that in the DAGBuilder metadata information connected with LoadInst instruction is utilized:
bool isInvariant = I.getMetadata(LLVMContext::MD_invariant_load) != nullptr;

Is this metadata somehow protected against dropping - as you mentioned?

Nothing is protected as far as I know, the design is that it should always be legal to drop a metadata.
I don’t know what the invariant_load information is used for at the place you looked at, but I assume that I can take the IR, strip it out of the “invariant_load” metadata from the loads, and optimizations/codegen should still be correct. If your use-case fits in this model then metadata is likely a good starting point.

In my case dropping metadata shouldn’t cause functional issues, eventual only performance - different pattern would be chosen. So I will start with utilizing metadata.

Regards,
Przemek

7

I want to customize handling of ‘load’ instruction during processing DAG, but on IR level I want the ‘load’ to be treated in different passes as common load. So I’m afraid that replacing ‘load’ with Intrinsic would cause different handling it comparing to LoadInst.

Yes this is the kind of replacement you would do after the general optimizations.
If you need to attach this information when you create the IR (from the front-end directly for example) then intrinsics or metadatas are the only two ways I know of.
Depending on what is it exactly that you are trying to model, function attributes can be used but they would apply to the whole function (or specific arguments). It may also be possible to use an intrinsic to mark the pointer itself instead of the instructions manipulating it, again it depends on what you are modelling.

So you are suggesting to replace something like:
%ptr = alloca i32
%val = load i32, i32* %ptr

with

%ptr = alloca i32
%custom.ptr = call i32* @llvm.customhandling(i32* %ptr)
%val = load i32, i32* %custom.ptr

?

I had in mind something like:

%ptr = alloca i32

%custom.ptr = call i32* @llvm.customhandling(i32* %ptr)

Then use only the custom.ptr, never ptr.
But every approach will have its tradeoff, so it really depends on the use-case.

8

This could be interesting alternative to utilizing metadata. Now I will consider usage of each other - metadata vs. intrinsic.

Thanks Mehdi for these ideas! I haven’t thought about usage intrinsic just for pointer.

Best regards,
Przemek

czw., 2 maj 2019, 18:37 użytkownik Mehdi AMINI <joker.eph@gmail.com> napisał: