Aik Hui writes:
>
....
> /* I guess that the above is the continuation / return vector for the case
> stmt? And if so ... I think the first address is the first branch which
> is suppose to return (0,0) ? */
>
> IFN_(djn_C5GZ_1) {
> ED_RO_(Tup2_inregs_info)
>
> FB_
> R3.p = SpA[2];
> R4.p = SpA[1];
> SpA = SpA + 6;
> SpB = SpB - 1;
> R2.d=Tup2_inregs_info
>
> JMP_(DIRECT((StgRetAddr (SpB[1])));
> FE_
> }
>
...
>
> Question:
>
> 1. Am I correct to say that the return tuple was never built at all but
> returned through registers? And if so, what is Tup2_inregs_info?
>
That's right, a (so-called) phantom constructor is returned here. R2
is loaded with the info table for the phantom constructor(i.e.,
Tup2_inregs_info), which has standard entry code which just does an
update.
>
> 2. Does ghc compile all tuples to return in registers? Or does it do so
> for tuples up to a certain length?
>
It depends, by default the code generator will try to do a
return-in-regs for constructors, employing all free registers. If it
should run out of registers of some sort, it falls back to a
return-in-heap convention.
If you're Brave and want to experiment, the number of vanilla
registers to use when doing the register allocation can be
controlled via the (experimental) -freturn-in-regs-threshold
cmd-line option, i.e., -freturn-in-regs-threshold6 .
> 3. Is there a guide for us to decipher abstractC syntax... or perhaps the
> more common stuff like:
>
> IFN_(...)
> ED_RO_(...)
> ID_RO_(...)
...
There's always the source..:-) AFAIK, no docs that gives a roadmap
of what all these macros Really Mean. StgMacros.l?h and SMClosure.l?h
are of invaluable help, though.
This is just my take on things, i.e., CG Honchos, please chip in if
all of this radically clashes with reality.
--Sigbjorn
