This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR target/70155: Use SSE for TImode load/store
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Ilya Enkovich <enkovich dot gnu at gmail dot com>
- Date: Tue, 26 Apr 2016 11:33:32 +0200
- Subject: Re: [PATCH] PR target/70155: Use SSE for TImode load/store
- Authentication-results: sourceware.org; auth=none
- References: <20160425125145 dot GA5326 at intel dot com> <CAFULd4ZFMuMR0UVtxYL6teuO-CABSJv6QbqXhkU5DX5F_aGdYQ at mail dot gmail dot com> <CAMe9rOrzOZYGSwq9g9aj3xSjSHnGuBJh_rmFTai0V7eUPkaSTw at mail dot gmail dot com> <CAFULd4Z54Gv2GQcjz=qfmd0PSaON44zz-h7SWBvKLhTzgOOzKg at mail dot gmail dot com> <alpine dot LSU dot 2 dot 11 dot 1604261116090 dot 13384 at t29 dot fhfr dot qr>
On Tue, Apr 26, 2016 at 11:17 AM, Richard Biener <rguenther@suse.de> wrote:
> On Mon, 25 Apr 2016, Uros Bizjak wrote:
>
>> On Mon, Apr 25, 2016 at 4:47 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> > On Mon, Apr 25, 2016 at 7:18 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>> >> On Mon, Apr 25, 2016 at 2:51 PM, H.J. Lu <hongjiu.lu@intel.com> wrote:
>> >>> Tested on Linux/x86-64. OK for trunk?
>> >>
>> >>> + /* FIXME: Since the CSE pass may change dominance info, which isn't
>> >>> + expected by the fwprop pass, call free_dominance_info to
>> >>> + invalidate dominance info. Otherwise, the fwprop pass may crash
>> >>> + when dominance info is changed. */
>> >>> + if (TARGET_64BIT)
>> >>> + free_dominance_info (CDI_DOMINATORS);
>> >>> +
>> >>
>> >> Please resolve the above problem first, target-dependent sources are
>> >> not the place to apply band-aids for middle-end problems. The thread
>> >> with the proposed fix died in [1].
>> >>
>> >> [1] https://gcc.gnu.org/ml/gcc/2016-03/msg00143.html
>> >
>> > free_dominance_info (CDI_DOMINATORS) has been called in other
>> > places to avoid this middle-end issue. I don't know when the middle-end
>> > will be fixed. I don't think this target optimization should be penalized by
>> > the middle-end issue.
>>
>> Let's ask Richard if he is OK with the workaround...
>
> Well, it's ultimately your call (it's a workaround in the target).
Oh well, ...
> Of course I'd like to see the underlying issue fixed and the
> workarounds in "other places" be removed.
... then at least a reference to a relevant PR should be added to a
FIXME comment.
Uros.