Page MenuHomePhabricator

zuban32 (Aleksandr Bezzubikov)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 29 2021, 6:43 AM (8 w, 6 h)

Recent Activity

May 21 2021

zuban32 added a comment to D101538: [GlobalISel][IRTranslator] Make translate() methods virtual..

I wouldn't be so sure about that. One particular usecase I need this for is a bitcast between pointer types:

%1 = bitcast i8* %0 to %struct.ST*
In our target they're both of p0 LLTs, so the default method eliminates this instruction while in our target it's necessary to keep it.

That sounds like you're abusing the IR here. Shouldn't you have a different addrspace here?

FWIW, when we discussed the design of GISel internally originally we explicitly chose not to allow virtual overloading of the IR translation steps because that step follow what is represented in the IR.
To make a parallel with SDISel, this is as if we would allow SDISelBuilder to be target specific.

Bottom line, for just this one use case I feel that it doesn't make sense to allow virtual method everywhere yet.

You could workaround that with introducing a pseudo/intrisinc in codegen prepare for instance.

My 2 cents.

Cheers,
-Quentin

May 21 2021, 7:23 AM · Restricted Project

May 19 2021

zuban32 added a comment to D101538: [GlobalISel][IRTranslator] Make translate() methods virtual..

Won't this problem go away when we introduce FP LLTs?

I wouldn't be so sure about that. One particular usecase I need this for is a bitcast between pointer types:

%1 = bitcast i8* %0 to %struct.ST*

In our target they're both of p0 LLTs, so the default method eliminates this instruction while in our target it's necessary to keep it.

What are you going to do when IR switches to opaque pointers? https://llvm.org/docs/OpaquePointers.html

May 19 2021, 8:50 AM · Restricted Project

May 18 2021

zuban32 added a comment to D101538: [GlobalISel][IRTranslator] Make translate() methods virtual..

Is this really necessary? Our preference is to use custom combines/lowering passes, or custom legalization, to do this.

Well, our usecase might not be that canonical, let me briefly explain. For example, translating a bitcast - default IRTranslator implementation turns it into a COPY when LLTs of src and dst are the same. In our target (SPIR-V) LLTs do not matter that much, the typeinfo is represented with some pseudo instructions, so we run into this situation quite often. And losing a bitcast in the translator doesn't work for us as it'd obviously be quite difficult to recover it.

Won't this problem go away when we introduce FP LLTs?

May 18 2021, 11:35 AM · Restricted Project

May 17 2021

zuban32 added a comment to D101538: [GlobalISel][IRTranslator] Make translate() methods virtual..

@aemerson @foad if no one has any idea how to make CRTP approach feasible here, then I'd suggest to merge this, I have no write access though

May 17 2021, 9:11 AM · Restricted Project

May 13 2021

zuban32 added a comment to D101538: [GlobalISel][IRTranslator] Make translate() methods virtual..

Is this really necessary? Our preference is to use custom combines/lowering passes, or custom legalization, to do this.

Well, our usecase might not be that canonical, let me briefly explain. For example, translating a bitcast - default IRTranslator implementation turns it into a COPY when LLTs of src and dst are the same. In our target (SPIR-V) LLTs do not matter that much, the typeinfo is represented with some pseudo instructions, so we run into this situation quite often. And losing a bitcast in the translator doesn't work for us as it'd obviously be quite difficult to recover it.

I see. Is this a widespread issue with a lot of the translation functions or just bitcasts? If it's just bitcast you could just make that virtual so we don't have to pay the virtual function call overhead every translate. If not, then I'm ok with doing this.

How about doing it with https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern#Static_polymorphism to avoid the virtual function call overhead?

May 13 2021, 3:18 PM · Restricted Project

May 11 2021

zuban32 added a comment to D101538: [GlobalISel][IRTranslator] Make translate() methods virtual..

Is this really necessary? Our preference is to use custom combines/lowering passes, or custom legalization, to do this.

Well, our usecase might not be that canonical, let me briefly explain. For example, translating a bitcast - default IRTranslator implementation turns it into a COPY when LLTs of src and dst are the same. In our target (SPIR-V) LLTs do not matter that much, the typeinfo is represented with some pseudo instructions, so we run into this situation quite often. And losing a bitcast in the translator doesn't work for us as it'd obviously be quite difficult to recover it.

I see. Is this a widespread issue with a lot of the translation functions or just bitcasts? If it's just bitcast you could just make that virtual so we don't have to pay the virtual function call overhead every translate. If not, then I'm ok with doing this.

May 11 2021, 12:34 PM · Restricted Project
zuban32 added a comment to D101538: [GlobalISel][IRTranslator] Make translate() methods virtual..

Is this really necessary? Our preference is to use custom combines/lowering passes, or custom legalization, to do this.

May 11 2021, 8:58 AM · Restricted Project

May 7 2021

zuban32 added a comment to D101538: [GlobalISel][IRTranslator] Make translate() methods virtual..

Gentle ping

May 7 2021, 3:35 PM · Restricted Project

Apr 29 2021

zuban32 added reviewers for D101538: [GlobalISel][IRTranslator] Make translate() methods virtual.: aemerson, qcolombet, t.p.northover, paquette, foad.
Apr 29 2021, 5:18 PM · Restricted Project
zuban32 updated the diff for D101538: [GlobalISel][IRTranslator] Make translate() methods virtual..

Rebased

Apr 29 2021, 11:54 AM · Restricted Project
zuban32 requested review of D101538: [GlobalISel][IRTranslator] Make translate() methods virtual..
Apr 29 2021, 7:40 AM · Restricted Project