* [PATCH] Use HOST_WIDE_INT_C some more in the i386 backend
@ 2016-05-13 17:11 Jakub Jelinek
2016-05-13 17:23 ` Uros Bizjak
0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2016-05-13 17:11 UTC (permalink / raw)
To: Uros Bizjak, Kirill Yukhin; +Cc: gcc-patches
Hi!
I found a couple of spots where we can use the HOST_WIDE_INT_C macro.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-05-13 Jakub Jelinek <jakub@redhat.com>
* config/i386/i386.c (ix86_compute_frame_layout, ix86_expand_prologue,
ix86_expand_split_stack_prologue): Use HOST_WIDE_INT_C macro.
(ix86_split_to_parts): Likewise. Fix up formatting.
--- gcc/config/i386/i386.c.jj 2016-05-12 09:46:40.000000000 +0200
+++ gcc/config/i386/i386.c 2016-05-12 10:46:35.862566575 +0200
@@ -11957,7 +11957,7 @@ ix86_compute_frame_layout (struct ix86_f
to_allocate = offset - frame->sse_reg_save_offset;
if ((!to_allocate && frame->nregs <= 1)
- || (TARGET_64BIT && to_allocate >= (HOST_WIDE_INT) 0x80000000))
+ || (TARGET_64BIT && to_allocate >= HOST_WIDE_INT_C (0x80000000)))
frame->save_regs_using_mov = false;
if (ix86_using_red_zone ()
@@ -13379,7 +13379,7 @@ ix86_expand_prologue (void)
{
HOST_WIDE_INT size = allocate;
- if (TARGET_64BIT && size >= (HOST_WIDE_INT) 0x80000000)
+ if (TARGET_64BIT && size >= HOST_WIDE_INT_C (0x80000000))
size = 0x80000000 - STACK_CHECK_PROTECT - 1;
if (TARGET_STACK_PROBE)
@@ -14320,7 +14320,7 @@ ix86_expand_split_stack_prologue (void)
different function: __morestack_large. We pass the
argument size in the upper 32 bits of r10 and pass the
frame size in the lower 32 bits. */
- gcc_assert ((allocate & (HOST_WIDE_INT) 0xffffffff) == allocate);
+ gcc_assert ((allocate & HOST_WIDE_INT_C (0xffffffff)) == allocate);
gcc_assert ((args_size & 0xffffffff) == args_size);
if (split_stack_fn_large == NULL_RTX)
@@ -24554,20 +24554,17 @@ ix86_split_to_parts (rtx operand, rtx *p
real_to_target (l, CONST_DOUBLE_REAL_VALUE (operand), mode);
/* real_to_target puts 32-bit pieces in each long. */
- parts[0] =
- gen_int_mode
- ((l[0] & (HOST_WIDE_INT) 0xffffffff)
- | ((l[1] & (HOST_WIDE_INT) 0xffffffff) << 32),
- DImode);
+ parts[0] = gen_int_mode ((l[0] & HOST_WIDE_INT_C (0xffffffff))
+ | ((l[1] & HOST_WIDE_INT_C (0xffffffff))
+ << 32), DImode);
if (upper_mode == SImode)
parts[1] = gen_int_mode (l[2], SImode);
else
- parts[1] =
- gen_int_mode
- ((l[2] & (HOST_WIDE_INT) 0xffffffff)
- | ((l[3] & (HOST_WIDE_INT) 0xffffffff) << 32),
- DImode);
+ parts[1]
+ = gen_int_mode ((l[2] & HOST_WIDE_INT_C (0xffffffff))
+ | ((l[3] & HOST_WIDE_INT_C (0xffffffff))
+ << 32), DImode);
}
else
gcc_unreachable ();
Jakub
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] Use HOST_WIDE_INT_C some more in the i386 backend
2016-05-13 17:11 [PATCH] Use HOST_WIDE_INT_C some more in the i386 backend Jakub Jelinek
@ 2016-05-13 17:23 ` Uros Bizjak
0 siblings, 0 replies; 2+ messages in thread
From: Uros Bizjak @ 2016-05-13 17:23 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Kirill Yukhin, gcc-patches
On Fri, May 13, 2016 at 7:11 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> I found a couple of spots where we can use the HOST_WIDE_INT_C macro.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2016-05-13 Jakub Jelinek <jakub@redhat.com>
>
> * config/i386/i386.c (ix86_compute_frame_layout, ix86_expand_prologue,
> ix86_expand_split_stack_prologue): Use HOST_WIDE_INT_C macro.
> (ix86_split_to_parts): Likewise. Fix up formatting.
OK.
Thanks,
Uros.
> --- gcc/config/i386/i386.c.jj 2016-05-12 09:46:40.000000000 +0200
> +++ gcc/config/i386/i386.c 2016-05-12 10:46:35.862566575 +0200
> @@ -11957,7 +11957,7 @@ ix86_compute_frame_layout (struct ix86_f
> to_allocate = offset - frame->sse_reg_save_offset;
>
> if ((!to_allocate && frame->nregs <= 1)
> - || (TARGET_64BIT && to_allocate >= (HOST_WIDE_INT) 0x80000000))
> + || (TARGET_64BIT && to_allocate >= HOST_WIDE_INT_C (0x80000000)))
> frame->save_regs_using_mov = false;
>
> if (ix86_using_red_zone ()
> @@ -13379,7 +13379,7 @@ ix86_expand_prologue (void)
> {
> HOST_WIDE_INT size = allocate;
>
> - if (TARGET_64BIT && size >= (HOST_WIDE_INT) 0x80000000)
> + if (TARGET_64BIT && size >= HOST_WIDE_INT_C (0x80000000))
> size = 0x80000000 - STACK_CHECK_PROTECT - 1;
>
> if (TARGET_STACK_PROBE)
> @@ -14320,7 +14320,7 @@ ix86_expand_split_stack_prologue (void)
> different function: __morestack_large. We pass the
> argument size in the upper 32 bits of r10 and pass the
> frame size in the lower 32 bits. */
> - gcc_assert ((allocate & (HOST_WIDE_INT) 0xffffffff) == allocate);
> + gcc_assert ((allocate & HOST_WIDE_INT_C (0xffffffff)) == allocate);
> gcc_assert ((args_size & 0xffffffff) == args_size);
>
> if (split_stack_fn_large == NULL_RTX)
> @@ -24554,20 +24554,17 @@ ix86_split_to_parts (rtx operand, rtx *p
> real_to_target (l, CONST_DOUBLE_REAL_VALUE (operand), mode);
>
> /* real_to_target puts 32-bit pieces in each long. */
> - parts[0] =
> - gen_int_mode
> - ((l[0] & (HOST_WIDE_INT) 0xffffffff)
> - | ((l[1] & (HOST_WIDE_INT) 0xffffffff) << 32),
> - DImode);
> + parts[0] = gen_int_mode ((l[0] & HOST_WIDE_INT_C (0xffffffff))
> + | ((l[1] & HOST_WIDE_INT_C (0xffffffff))
> + << 32), DImode);
>
> if (upper_mode == SImode)
> parts[1] = gen_int_mode (l[2], SImode);
> else
> - parts[1] =
> - gen_int_mode
> - ((l[2] & (HOST_WIDE_INT) 0xffffffff)
> - | ((l[3] & (HOST_WIDE_INT) 0xffffffff) << 32),
> - DImode);
> + parts[1]
> + = gen_int_mode ((l[2] & HOST_WIDE_INT_C (0xffffffff))
> + | ((l[3] & HOST_WIDE_INT_C (0xffffffff))
> + << 32), DImode);
> }
> else
> gcc_unreachable ();
>
> Jakub
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-05-13 17:23 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-13 17:11 [PATCH] Use HOST_WIDE_INT_C some more in the i386 backend Jakub Jelinek
2016-05-13 17:23 ` Uros Bizjak
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).