public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: ak@muc.de
To: egcs@cygnus.com
Subject: Feature request: ability to describe x86 register halves as contraints.
Date: Mon, 29 Jun 1998 20:41:00 -0000	[thread overview]
Message-ID: <19980629184404.62482@kali.lrz-muenchen.de> (raw)

Hallo, 

Egcs does not handle x86 register halves (al/ah etc.) well. Although
it is able to turn (x & 0xFF) into an access to the rL register, there
is no way to trick it into generating write access to rH registers
(neither union { char h,l; short val } x; x.h = 1; nor and/shift/or tricks
work). 

It is often good for the code to use the register halves, because in 
algorithms which operate on 8 values (e.g. some ciphers) the ability
to access register halves effectively adds 4 more 8bit registers.
Because the x86 CPUs are so register starved this can speed some inner
loops up considerably.

I understand that making gcc do this automatically is a non-trivial
amount of work. 

To optimize a critical inner loop I've resorted to use inline assembly
in some critical computations to work directly on the 8bit halves. 
Unfortunately I've hit a limitation of the gcc constraints language
now. There is no way to describe:

"Give me a 16bit register, but insert the high/low byte form of the register-
name here." 

e.g.  it should pass in a 16bit value in a register like AX, but insert
into the assembler template AH or AL depending on a special flag. 

The only way to do this is to use fixed input registers and hardcode the 
register halves. Unfortunately this adds some compiler version dependencies
to my code, and also limits the possibilities of the compiler to do other
optimizations. 

Is it possible to add such an extension to the constraints language? 
Hopefully only minimal changes should be needed for this. 

-Andi


             reply	other threads:[~1998-06-29 20:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-06-29 20:41 ak [this message]
1998-06-30  0:42 ` Richard Henderson
1998-06-30  4:50   ` ak
1998-06-30 19:49     ` Alan Modra
1998-06-30 19:49       ` Andreas Kleen
1998-06-30 14:08   ` Jeffrey A Law
1998-06-30  9:24     ` Richard Henderson
1998-06-30  1:02 ` Jeffrey A Law
1998-06-30 11:53   ` Joern Rennecke
1998-06-30 11:53     ` Jeffrey A Law
1998-07-01  3:42       ` Richard Henderson
1998-06-30 15:15   ` Bill Currie
1998-06-30 15:26     ` Jeffrey A Law
1998-06-30 23:15       ` Bill Currie
1998-06-30 19:49         ` Jeffrey A Law
1998-07-01 10:51           ` Joern Rennecke
1998-07-01 10:51             ` Jeffrey A Law
1998-07-01 13:20 Michael Meissner
1998-07-01 20:15 ` Joern Rennecke
     [not found] <359ABD84.2FC4@tssc.co.nz>
1998-07-02  1:39 ` Jeffrey A Law
1998-07-02  1:39   ` Bill Currie
1998-07-02  1:39     ` Jeffrey A Law
1998-07-03  0:12       ` Bill Currie
1998-07-02 11:02     ` Joern Rennecke
1998-07-02 15:15       ` Bill Currie
1998-07-02 15:15         ` Joern Rennecke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19980629184404.62482@kali.lrz-muenchen.de \
    --to=ak@muc.de \
    --cc=egcs@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).