On Tue, 2012-11-20 at 10:27 +0200, Stefan Kristiansson wrote: > On Tue, Nov 20, 2012 at 08:50:38AM +0100, Jonas Bonn wrote: > > > > The register that immediately jumps out at me as a natural choice is > > r11... that register then becomes an IN/OUT parameter and doesn't > > disrupt the regular allocation of parameter registers where r3 usually > > is the first parameter. > > > > But I've given this about 3 minutes of thought; maybe r3 is better. I > > would, however, be curious to know why in that case... > > > > Ah, I didn't necessarily mean it's a better choice than r11, > just that it doesn't really cause any trouble. > I'm not supersure about the whole thing neither, but this is what we have. > But if we expand on that thought, why do we even have seperate return > registers, couldn't r3 and r4 be combined return value and function > parameters? > A bit late to change that, but still.
Yes, I think it's too late for that... ABIv2 perhaps, but not now. > > I'm not sure about the disrupting the reg allocator, from what I remember > in LLVM it's automatically assigned to the first function parameter. OK, this is a valid argument... BUT, LLVM must be able to handle this, if anybody can! :) > > > > > > > 16.2.5 Functions Returning Structures or Unions > > > > > > A function that returns a structure or union places the address of the > > > structure or > > > union in the general-purpose RV register. > > > > > > A function that returns a structure by value expects the > > > location where that > > > structure is to be placed to be supplied in function parameter word 0 > > > (R3). > > > > This means we put X in r3 going into the function call and get X in r11 > > coming out... what's the point? > > > > Actually, I asked the same thing and was inclined to omit putting X in r11 > in LLVM. > > Joern came with this input regarding the issue (hope he don't mind I quote the > IRC conversation here): > > < amylaar> Hello, I heard you have a question for me? > < stekern> amylaar: yes, I was speaking with jeremybennett about the ABI for > returning structs, and I was trying to come up with a case where the pointer > in r11 actually would be used > < stekern> since the struct is returned on the callers stack, it will already > know about the pointer > < amylaar> The callee has to know where to put it. > < stekern> yes, but that is passed in r3 > < stekern> I was wondering about the return value in r11 > < stekern> and if the caller ever will use the pointer that is returned in > r11, or if it will just always use the stack offset that it has already > calculated (my small tests indicates the latter) > < amylaar> In general, it will be most convenient for the caller to tell the > callee where it wants the value, and then be happy with where it knows it is. > < amylaar> But I could imagine that there are some cases where having the > pointer in r11 is convenient. > < amylaar> Like, when the caller in turn is supposed to return a pointer to > that kind of struct, which it allocated (e.g. with malloc). > < amylaar> So, ideally, it would pass the address of that allocated storage > to its callee, and it can do a tail-call, as the return value of the callee > will be the same as that of the caller. I don't see how this answers the question of when r11 will be used. r11 will just be a copy of r3 coming out of the function, while r3 will be clobbered. Wouldn't it be better to put the location in r11, save yourself the copy from r3 to r11, and r11 effectively becomes call-saved through the function. GCC, like you said, will optimize all this down to just offset manipulation, anyway, so ultimately the register barely needs to be set at all. (I wrote that last paragraph while running out the door... it might not make sense at all :) ) /Jonas > > Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
