> At 11:20 AM 7/20/2001 +0100, Ben Harris wrote:
> >MASK_RETURN_ADDR needs to be changed to generate code to check what mode
> >the CPU is in at run-time and pick the correct mask appropriately.
> >sys/arch/arm/include/profile.h demonstrates how to do this, but it needs
> >to be converted to a form GCC can understand.
> 
> Is there any reason why this has to be done dynamically?  Why can't crt0.o
> calculate the mask and store it somewhere so that gcc generated code can
> reference it?

It takes four data-processing instructions to generate the mask 
dynamically.  To load the mask would require only three, but two of these 
would be memory accesses; in addition, you would need two words of storage 
somewhere, (one for the address of the location holding the mask, and one 
for the mask itself.  Given the number of routines that need to use this 
code (in most C programs, typically, none; in C++ typically one), it's not 
worth the hassle of pre-evaluating.

>  (But that gets nasty for PIC code.) 

PIC would probably add one more cycle to the above.

> The other alternative
> it to use an UNSPEC rtx to calculate and put a matching pattern in arm.md.
> But I haven't quite figured out UNSPEC rtx's.

Which is what I did in the patch I sent to Ben yesterday.

We've wasted enough brain cycles on this problem already.  Lets not waste 
any more.

R.