public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jeff Law <law@redhat.com>, Evgeny Stupachenko <evstupac@gmail.com>
Cc: Vlad Makarov <vmakarov@redhat.com>,
	Uros Bizjak <ubizjak@gmail.com>,
	       GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 1/X, i386, PR54232] Enable EBX for x86 in 32bits PIC code
Date: Tue, 14 Oct 2014 13:02:00 -0000	[thread overview]
Message-ID: <20141014130051.GB10376@tucnak.redhat.com> (raw)
In-Reply-To: <5438035A.1030408@redhat.com>

On Fri, Oct 10, 2014 at 10:03:38AM -0600, Jeff Law wrote:
> Can you add a PR markers to your changelog
> 
> 	PR target/8340
> 	PR middle-end/47602
> 	PR rtl-optimization/55458
> 
> Actually I think there is an additional test in 47602.  Can you please add
> it to the suite?  You'll also want to change the state of 47602 to
> RESOLVED/FIXED.

Unfortunately this broke bootstrap on x86_64/i686-linux,
see http://gcc.gnu.org/PR63534
- pretty much everything with -m32 -fsplit-stack -fpic ICEs, -m32 -fpic -p
results in wrong-code, and I see significant code quality regressions even
on simple testcases.

For the first two, I think (and said it before already) that the current
model of emitting set_got from a target hook during RA can't work, as there
can be calls in the prologue, and the prologue is inserted before the
set_got in that case.  I really think the RA should in that case just tell
the backend whether and in which register it wants to have the PIC register
loaded upon start of the function, and it should be emit prologue pass
that should arrange for that.

As for the code quality, either some RA improvements are needed, or
postreload must be able to fix it up, or hardreg propagation (though,
cprop_hardreg is forward propagation rather than backwards, right?).
Better before prologue is emitted though, because that will save/restore
the badly chosen hard reg too.

	Jakub

  parent reply	other threads:[~2014-10-14 13:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-10  7:43 Evgeny Stupachenko
2014-10-10 15:31 ` Vladimir Makarov
2014-10-10 16:11 ` Jeff Law
2014-10-13 14:53   ` Evgeny Stupachenko
2014-10-13 16:24     ` Uros Bizjak
2014-10-13 16:33       ` Evgeny Stupachenko
2014-10-13 16:33         ` Uros Bizjak
2014-10-13 18:52         ` H.J. Lu
2014-10-14 15:02           ` H.J. Lu
2014-10-23 13:20         ` Rainer Orth
2014-10-29 12:42           ` Evgeny Stupachenko
2014-10-29 19:54             ` Uros Bizjak
2014-10-13 16:30     ` Jeff Law
2014-10-14 13:02   ` Jakub Jelinek [this message]
2014-10-14 16:55     ` Jeff Law
2014-10-14 17:02       ` H.J. Lu

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=20141014130051.GB10376@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=evstupac@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=ubizjak@gmail.com \
    --cc=vmakarov@redhat.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).