This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: inline asm constraints for conditions


On Mon, Sep 29, 2003 at 01:17:18PM -0400, David Edelsohn wrote:
> >>>>> Richard Henderson writes:
> 
> Richard> For PPC, you'd have to have a builtin type to get access PQImode or CCmode.
> Richard> You'd then need a builtin function to get access to the bits you want to
> Richard> use out of the condition (__builtin_cc_gtu(x), or maybe just
> Richard> __builtin_ppc_compare(x, <4-bit-immediate>)).  The only bit of ugliness
> Richard> here is that you might have to hack the generic compare-and-branch 
> Richard> expansion code to make this work, much as we did for __builtin_expect.
> 
> Richard> I could see that it would be possible to make this work on PPC, since
> Richard> there are 8 of these registers to allocate, three of which are even
> Richard> call-saved.  "A mere matter of programming", as they say.
> 
> 	An optimization opportunity for PowerPC is to treat the condition
> register bitfields as bitfields.  Instead of interpreting the CR bits as
> representing different comparison results, use the appropriate branch
> instruction to test the bitfield bits of interest.

Ugh, I don't understand anything in this. Sorry. 

One thing I've done in a few cases when testing several flags in PPC
assembly is moving the flags to CR with an mtcrf instruction and
then use bt/bf on the corresponding bit. This eliminates quite a few
testing instructions and allows to prepare the CR field(s) well in
advance. GCC does not do anything remotely similar AFAICT. 
Is this kind of technique what you have in mind?

This said, I have no idea on how to hack GCC to do this :-(

	Regards,
	Gabriel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]