Re: [PATCH] MIPS/GCC: Mark text contents as code or data

[Maciej W. Rozycki]

Hi Paul,

 Apologies for the delay in reply, my @imgtec.com address has since become 
defunct and I have only come across your e-mail in my ever-lagging routine 
mailing traffic review.

On Wed, 14 Mar 2018, Paul Hua wrote:

> I noticed that data-sym-pool.c fails on -O0 flags.
> 
> -O0 output :
> -cut--
> frob:
> .frame  $17,8,$31   # vars= 0, regs= 1/0, args= 0, gp= 0
> .mask   0x0002,0
> .fmask  0x,0
> addiu   $sp,-8
> sd  $17,0($sp)
> move$17,$sp
> lw  $2,$L4
> move$sp,$17
> ld  $17,0($sp)
> addiu   $sp,8
> jr  $31
> .type   __pool_frob_3, @object
> __pool_frob_3:
> .align  2
> $L3:
> .word   __gnu_local_gp
> $L4:
> .word   305419896
> .type   __pend_frob_3, @function
> __pend_frob_3:
> .insn
> .endfrob
> .size   frob, .-frob
> .ident  "GCC: (gcc trunk r258495 mips64el o32 n32 n64) 8.0.1
> 20180313 (experimental)"
> -end--
> 
> Is it expected ? maybe we should add skip-if  -O0 flags.

 Thanks for your report.

 I think instead we should relax the matching pattern and also accept an 
arbitrary number of label-`.word' pairs ahead of and/or after the required 
one in the constant pool.  I'll post a fix.

  Maciej

Re: [PATCH] MIPS/GCC: Mark text contents as code or data

[Paul Hua]

I noticed that data-sym-pool.c fails on -O0 flags.

-O0 output :
-cut--
frob:
.frame  $17,8,$31   # vars= 0, regs= 1/0, args= 0, gp= 0
.mask   0x0002,0
.fmask  0x,0
addiu   $sp,-8
sd  $17,0($sp)
move$17,$sp
lw  $2,$L4
move$sp,$17
ld  $17,0($sp)
addiu   $sp,8
jr  $31
.type   __pool_frob_3, @object
__pool_frob_3:
.align  2
$L3:
.word   __gnu_local_gp
$L4:
.word   305419896
.type   __pend_frob_3, @function
__pend_frob_3:
.insn
.endfrob
.size   frob, .-frob
.ident  "GCC: (gcc trunk r258495 mips64el o32 n32 n64) 8.0.1
20180313 (experimental)"
-end--

Is it expected ? maybe we should add skip-if  -O0 flags.

Paul Hua


On Thu, Nov 17, 2016 at 1:15 AM, Maciej W. Rozycki  wrote:
> On Tue, 15 Nov 2016, Matthew Fortune wrote:
>
>> I'm a little concerned the expected output tests may be fragile over
>> time but let's wait and see.
>
>  Indeed, but I'd rather see false negatives than false positives or no
> coverage at all.  And I hope the pieces of expected assembly quoted will
> help telling any false negatives and actual regressions apart very easily.
>
>> OK to commit.
>
>  Applied now, thanks for your review.
>
>   Maciej

RE: [PATCH] MIPS/GCC: Mark text contents as code or data

[Maciej W. Rozycki]

On Tue, 15 Nov 2016, Matthew Fortune wrote:

> I'm a little concerned the expected output tests may be fragile over
> time but let's wait and see.

 Indeed, but I'd rather see false negatives than false positives or no 
coverage at all.  And I hope the pieces of expected assembly quoted will 
help telling any false negatives and actual regressions apart very easily.

> OK to commit.

 Applied now, thanks for your review.

  Maciej

RE: [PATCH] MIPS/GCC: Mark text contents as code or data

[Matthew Fortune]

Maciej Rozycki  writes:
>   gcc/
>   * config/mips/mips-protos.h (mips_set_text_contents_type): New
>   prototype.
>   * config/mips/mips.h (ASM_OUTPUT_BEFORE_CASE_LABEL): New macro.
>   (ASM_OUTPUT_CASE_END): Likewise.
>   * config/mips/mips.c (mips_set_text_contents_type): New
>   function.
>   (mips16_emit_constants): Record the pool's initial label number
>   with the `consttable' insn.  Emit a `consttable_end' insn at the
>   end.
>   (mips_final_prescan_insn): Call `mips_set_text_contents_type'
>   for `consttable' insns.
>   (mips_final_postscan_insn): Call `mips_set_text_contents_type'
>   for `consttable_end' insns.
>   * config/mips/mips.md (unspec): Add UNSPEC_CONSTTABLE_END enum
>   value.
>   (consttable): Add operand.
>   (consttable_end): New insn.
> 
>   gcc/testsuite/
>   * gcc.target/mips/data-sym-jump.c: New test case.
>   * gcc.target/mips/data-sym-pool.c: New test case.
>   * gcc.target/mips/insn-pseudo-4.c: Adjust for constant pool
>   annotation.

Thanks for working on this it is really useful functionality.

I'm a little concerned the expected output tests may be fragile over
time but let's wait and see.

OK to commit.

Thanks,
Matthew