This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ia64] [PR target/57491] internal compiler error: in ia64_split_tmode -O2, quadmath
- From: Kirill Yukhin <kirill dot yukhin at gmail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches at gcc dot gnu dot org, wilson at tuliptree dot org, sellcey at mips dot com, jtaylor dot debian at gmail dot com
- Date: Mon, 18 Nov 2013 10:32:48 +0300
- Subject: Re: [ia64] [PR target/57491] internal compiler error: in ia64_split_tmode -O2, quadmath
- Authentication-results: sourceware.org; auth=none
- References: <20131107124234 dot GA2459 at msticlxl57 dot ims dot intel dot com> <1986179 dot bTccpBNqBR at polaris> <20131115135559 dot GA57982 at msticlxl57 dot ims dot intel dot com> <1778751 dot M32BEGYTTn at polaris>
On 16 Nov 10:03, Eric Botcazou wrote:
> > As far as I understand semantics of this insn:
> > (insn 200 199 0 (set (reg:DI 15 r15)
> > (mem:DI (post_dec:DI (reg/f:DI 15 r15 [447])) [3
> > *_61[_12]{lb: 1 sz: 64}.text+8 S8 A64])) -1 (nil))
> > What is done is (in that sequence).
> > 1. Calculate address of MEM: get r15 value.
> > 2. Decrement r15 value.
> > 3. Load MEM in to r15.
> >
> > Point 2 is useless as we kill it by 3.
> > So, it is clobbered and as mention in comment this is sometimes ok to
> > override pointer with pointer value.
>
> That depends on the semantics of the hardware instruction though, does it
> really guarantee 1/2/3 in that order?
I've read into IA-64 Spec and it states that if we have
same destination and address registers with post-update form then
`Illegal instruction' should be raised.
This not affects my recent patch.
> The patch looks good to me if you also adjust the last sentence in the comment
> just above the block:
>
> /* It is possible for reload to decide to overwrite a pointer with
> the value it points to. In that case we have to do the loads in
> the appropriate order so that the pointer is not destroyed too
> early. Also we must not generate a postmodify for that second
> load, or rws_access_regno will die. */
>
> Something like "And we must not generate a postmodify for the second load if
> the destination register overlaps with the base register".
Thanks, I'll check it in with proposed comment fix today.
Bootstrap (with all languages) pass.
--
Thanks, K