Broken link Extended-asm-with-goto.html#Extended-asm-with-goto in online HTML documentation

[Stephan Bergmann]

Not sure if it is already known, but noticed that at least in the online 
HTML documentation for all versions since 4.5 (where it was apparently 
introduced), at 
 in the 
paragraph


  Speaking of labels, jumps from one asm to another are not supported. 
The compiler's optimizers do not know about these jumps, and therefore 
they cannot take account of them when deciding how to optimize. See 
Extended asm with goto.


the link of "Extended asm with goto" is

  

to a non-existing




which gets redirected as

  


to a URL with non-matching spaces vs. hyphens in the fragment, so 
doesn't make the browser jump to the 
 
anchor.


Stephan

Re: Reload and addsi

[Ulrich Weigand]

Hendrik Greving wrote:

> Yes :) I am asking about 3.2.3 but I think the reload concepts should
> be about the same. From what I can tell, most of the code I looked at
> was almost identical to GCC 4.7.3.

Yes, but it was completely rewritten for GCC 4.8 :-)

See e.g. the following email (and the thread leading up to it and
following it) for an extensive discussion of why we did this in
the past, and why we're now no longer doing it:

http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01421.html

> Note that we are setting the mode of the memory to the bigger
> (paradoxical) part of the subreg. How can we just set the mode, does
> somebody make sure this memory is actually allocated? I noticed even
> new GCC does that. Is this correct?

The code used to verify that this was OK by:

- proving that the updated memory address was naturally aligned
  for the larger access size, which means that the memory access
  would be guaranteed to not trap; of course, the particular
  values of the extra bytes read are undefined -- but that is
  OK according to the semantics of a paradoxical subreg.

- for the special case of accessing a stack (spill) slot that
  is assigned by the compiler in the first place, making sure
  that the stack slot is big enough to allow accesses in larger
  modes if such paradoxical subregs exist in the code.

> Going back where we call find_reloads_subreg_address:
> 
>  else if (regno >= FIRST_PSEUDO_REGISTER
> #ifdef LOAD_EXTEND_OP
>   && (GET_MODE_SIZE (GET_MODE (x))
>   <= GET_MODE_SIZE (GET_MODE (SUBREG_REG (x
> #endif
>   && (reg_equiv_address[regno] != 0
>   || (reg_equiv_mem[regno] != 0
>   && (! strict_memory_address_p (GET_MODE (x),
>  XEXP (reg_equiv_mem[regno], 0))
>   || ! offsettable_memref_p (reg_equiv_mem[regno])
>   || num_not_at_initial_offset
> x = find_reloads_subreg_address (x, 1, opnum, type, ind_levels,
> insn);
> 
> I have 2 questions here. Why does the fact whether or whether we don't
> have load extended ops matter when widening (or narrowing) the reload
> location (find_reloads_subreg_address)? Same question for
> req_equiv_address, why does this matter whether or not we end up
> widening/narrowing the memory location?

I agree that the particular condition cited above was not really
very precise; see the mail linked to above for discussion in
detail.  In the current (4.8) code this is much simplified :-)

> Generally speaking, does it look fine to you that we end up
> spilling/reloading mem:HI on the one hand, but mem:SI on the other?

The way we used to do it was correct (in most cases, including
your test case), but somewhat confusing and proved not particularly
useful in the end, so we changed it.  Current compilers will never
transform paradoxical subregs to accessing excess bytes in memory
any more.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Testing and branching with different modes

[Paulo Matos]

Hello,

My port seems to be slightly awkward in testing and branching compared to the 
existing one in mainline.
All the comparisons in my port set a QImode (8bits) register (predicate 
register), however branches branch on a single bit value of the predicate 
register.

So while I have:
tsteqb p0, r0, r1

which sets p0 to 0xff is r0 == r1, then the branch looks like
bl p0., , 
where
bl p0.0, L1

branches to L1 is bit 0 of p0 is set.

So I have cmp_qimode, etc but then only cbranchbi4.

My cbranchbi4 should look like this:
(define_insn "cbranchbi4"
  [(set (pc)
(if_then_else
 (match_operator 0 " easy_comparison"
 [(subreg:BI (match_operand:QI 1 "register" "c") 0)
  (match_operand:BI 2 "const0"   "")])
 (label_ref (match_operand 3 "" ""))
 (pc)))]
  ""...

or
(define_insn "cbranchbi4"
  [(set (pc)
(if_then_else
 (match_operator 0 " easy_comparison"
 [(and:BI (match_operand:QI 1 " register" "c")
  (const_int 1))
  (match_operand:BI 2 "const0"   "")])
 (label_ref (match_operand 3 "" ""))
 (pc)))]
  ""...


but both of these alternatives don't seem to be supported as it causes an ICE 
in patch_jump_insn.
What's the best way to deal with this situation? Is there any port out there 
with similar issues?

Cheers,

Paulo Matos

gcc-4.8-20130606 is now available

[gccadmin]

Snapshot gcc-4.8-20130606 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130606/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch 
revision 199768

You'll find:

 gcc-4.8-20130606.tar.bz2 Complete GCC

  MD5=4f8a922dc9eb8f7f1ec2622cffc201dd
  SHA1=0ecdf0e91c9c672c57fe6f61a618a59dee785fb2

Diffs from 4.8-20130530 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[RS6000] strict alignment for little-endian

[Alan Modra]

I'd like to remove -mstrict-align for little-endian powerpc, because
the assumption that mis-aligned accesses are massively slow isn't true
for current powerpc processors.  However I also don't want to break
old machines, so probably should add -mstrict-align back for some set
of cpus.  Can anyone tell me the set?

Index: gcc/config/rs6000/sysv4.h
===
--- gcc/config/rs6000/sysv4.h   (revision 199718)
+++ gcc/config/rs6000/sysv4.h   (working copy)
@@ -538,12 +538,7 @@
 
 #defineCC1_ENDIAN_BIG_SPEC ""
 
-#defineCC1_ENDIAN_LITTLE_SPEC "\
-%{!mstrict-align: %{!mno-strict-align: \
-%{!mcall-i960-old: \
-   -mstrict-align \
-} \
-}}"
+#defineCC1_ENDIAN_LITTLE_SPEC ""
 
 #defineCC1_ENDIAN_DEFAULT_SPEC "%(cc1_endian_big)"
 

-- 
Alan Modra
Australia Development Lab, IBM

Re: Testing and branching with different modes

[Richard Henderson]

On 2013-06-06 09:18, Paulo Matos wrote:

So while I have:
tsteqb p0, r0, r1

which sets p0 to 0xff is r0 == r1, then the branch looks like
bl p0., ,
where
bl p0.0, L1

branches to L1 is bit 0 of p0 is set.

So I have cmp_qimode, etc but then only cbranchbi4.


You'll be better off with a cbranchqi4 that expands to the comparison
insn and a special branch pattern.  I suggest ignoring BImode entirely
and using something like

(define_insn "*cbranch"
  [(set (pc)
(if_then_else
  (match_operator 2 "easy_comparison"
[(and:QI (match_operand:QI 0 "register_operand" "c")
 (const_int 1))
 (const_int 0)])
  (label_ref (match_operand 1 ""))
  (pc)))]
  ...)



r~