public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: law@redhat.com
To: Greg McGary <greg@mcgary.org>
Cc: gcc@gcc.gnu.org
Subject: Re: condition codes, haifa-sched and virtual-stack-vars
Date: Wed, 30 Jan 2002 12:42:00 -0000	[thread overview]
Message-ID: <12762.1012419024@porcupine.cygnus.com> (raw)
In-Reply-To: Your message of Wed, 30 Jan 2002 11:59:59 MST. <200201301859.g0UIxx606426@kayak.mcgary.org>

In message <200201301859.g0UIxx606426@kayak.mcgary.org>, Greg McGary writes:
 > I have a GCC port to a custom RISC that uses condition codes in an
 > explicit register (doesn't use cc0).  GCC generates bogus code when
 > expanding an inline.  One of the inline's args is the address of an
 > automatic, so it is passed to the inline as a move from
 > virtual-stack-vars to a pseudo.  Later, there's a conditional branch
 > on bitfield test that expands as bitfield-extract (shift + and),
 > comparison wtih zero, and branch.  All harmless so far.
 > 
 > Haifa-sched schedules the move from virtual-stack-vars between the
 > bitfield test sequence and the branch.  Later, global-reg alloc
 > instantiates virtual-stack-vars as an offset from FP, so the move
 > mutates into an add of fp+offset, clobbering the condition codes
 > computed earlier in the bitfield test.
 > 
 > One idea for a localized bandaid is to make the machine-description
 > wrap moves from virtual-stack-vars in a parallel that has a clobber
 > CC_REGNUM.  Another idea is to manipulate scheduling parameters so
 > that haifa doesn't schedule anything between CC set and CC use.
 > (I haven't yet looked at if/how this can be done.)
 > 
 > What's a better way to fix it?
If arithmetic clobbers the register, then that needs to be reflected in
the RTL for arithmetic.  Otherwise you're going to run into all kinds of
problems due to missing critical data dependency information in the
scheduler.

jeff






 > 
 > Thanks,
 > Greg


  reply	other threads:[~2002-01-30 19:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-30 12:31 Greg McGary
2002-01-30 12:42 ` law [this message]
2002-01-30 13:30   ` Greg McGary
2002-01-30 14:15     ` law
2002-01-31  7:49     ` Richard Earnshaw
2002-01-30 13:56 ` Alexandre Oliva
2002-01-30 17:13   ` Greg McGary
2002-01-30 17:20     ` Alexandre Oliva
2002-01-30 18:00       ` law
2002-01-30 19:23         ` Greg McGary
2002-01-31  5:53           ` Alexandre Oliva
2002-01-30 18:41 ` Richard Henderson
2002-01-30 15:19 Ulrich Weigand
2002-01-30 16:50 ` Geoff Keating
2002-01-30 17:13   ` Ulrich Weigand
2002-01-31 13:59     ` Geoff Keating
2002-01-30 19:31 ` Richard Henderson
2002-01-31 16:07   ` Ulrich Weigand
     [not found] <no.id>
2002-01-30 17:36 ` Ulrich Weigand

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=12762.1012419024@porcupine.cygnus.com \
    --to=law@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=greg@mcgary.org \
    /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).