[llvm-dev] Errononous scheduling of COPY instruction.

[Dominique Torette via llvm-dev]

Tim,

You are right, here is the definition of the MOV_AB_ro. No 'outs' !

	def	MOV_AB_ro	: CLPFPU_AB_ro<0b1000010011,
				(outs ),
				(ins FPUabRegisterOperand:$RegA, FPUabOffsetOperand:$OffsetB),
				[],[],
				"mov_ab\t$RegA,$OffsetB","",
				[],NoItinerary> {
			let mayLoad			= 1;
			let TSFlags{12}   = 1;
			let DecoderMethod = "DecodeFPURO_moveInstruction";
		}

My problem is that my processor has _not_ load/store instructions.
It does _not_ have external memory, only a bank of 512 internal registers...
So data memory, stack frames and temps are allocated from these 512 registers.  
It only has some MOV instructions, supporting two modes of addressing: register number addressing  (r) or offset register related addressing (o). 
These MOV instructions are sometime used to lower LOAD and sometime used to lower STORE.
So MOV instructions are a little ambiguous. Feel free to comment this architecture ;-)
To solve this ambiguity, I've introduced some LOAD PseudoInstroductions (with customInserters to MOV instructions).
These PseudoInstructions are used during Instruction Selection and Register Allocation. That works quite well.
But customInserters are called before the final scheduling. So the final scheduling is performed using the MOV instructions.
If well understood, I've to define the (outs ) for the destination of all my MOV definitions.
This will have many impact on my code (cusstomInserters, decoderMethods,...).
Could I use ImplictOuts to define dependency (less impact on the my code) ?

Thanks so much,	Dominique T.  

-----Original Message-----
From: Tim Northover [mailto:t.p.northover at gmail.com] 
Sent: jeudi 20 septembre 2018 17:43
To: Dominique Torette
Cc: LLVM Developers Mailing List
Subject: Re: [llvm-dev] Errononous scheduling of COPY instruction.

Hi Dominique,

On Thu, 20 Sep 2018 at 16:27, Dominique Torette via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>         MOV_AB_ro @s1, %fab_roff0
>         %6:fpuaoffsetclass = COPY %fab_roff0; FPUaOffsetClass:%6

The MOV_AB_ro instruction there is only reading %fab_roff0 so there's
no reason for LLVM to think it can't be swapped with the following
copy. Should it maybe write that register instead?

If not, what's the architectural constraint that *does* prevent
movement? we might be able to help with how you need to describe that
to LLVM.

Cheers.

Tim.


 ------------------------------------------------------------------------------

E-MAIL DISCLAIMER

The present message may contain confidential and/or legally privileged information. If you are not the intended addressee and in case of a transmission error, please notify the sender immediately and destroy this E-mail. Disclosure, reproduction or distribution of this document and its possible attachments is strictly forbidden.

SPACEBEL denies all liability for incomplete, improper, inaccurate, intercepted, (partly) destroyed, lost and/or belated transmission of the current information given that unencrypted electronic transmission cannot currently be guaranteed to be secure or error free.
Upon request or in conformity with formal, contractual agreements, an originally signed hard copy will be sent to you to confirm the information contained in this E-mail.

SPACEBEL denies all liability where E-mail is used for private use.

SPACEBEL cannot be held responsible for possible viruses that might corrupt this message and/or your computer system.
 -------------------------------------------------------------------------------