[patch][i386] Remove code executed only if reload_in_progress (i.e. never)

Uros Bizjak ubizjak@gmail.com
Thu Jan 9 08:16:00 GMT 2014


On Wed, Jan 8, 2014 at 10:58 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Jan 08, 2014 at 10:51:53PM +0100, Steven Bosscher wrote:
>> Hello Uros, and everyone else,
>>
>> Now that LRA is always used for the i386 targets, reload_in_progress
>> is never set so all code conditional on it is now dead. The attached
>> patch removes this code.
>>
>> Sadly I'm having difficulty testing the patch because I have no access
>> to a suitable x86_64 or ix86 box :-) I'll try to test the patch on a
>> compile farm machine, but I'm already posting the patch to hear if
>> this is still OK for this late stage of the development cycle. It's
>> not as if we're going to go back to reload so the code really is dead
>> AFAICT, but it's obviously not a bug fix.
>
> While LRA is always on, making it harder to test with reload doesn't seem to
> be a good idea to me for 4.9, when some RA issue is reported for these
> architectures, often one just patches config/i386/i386.c by hand to enable
> reload instead of LRA and tests it with that instead.  This patch would mean
> we'd need to keep around a patchset to apply for those purposes.

I also think that we should leave reload functionality in 4.9, for the
same reasons as Jakub presents.

IMO, LRA still has some rough edges, please see [1] that triggers with
improved x86 atomic_compare_and_swap<dwi>_doubleword pattern.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58945

Uros.



More information about the Gcc-patches mailing list