;
> Ulrich, can you look into this or do you want me to take a look here?
I'll have a look.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
fprintf (vect_dump, "not vectorized: unsupported alignment in basic "
+ "block.\n");
+
+ destroy_bb_vec_info (bb_vinfo);
+ return NULL;
+ }
+
if (!vect_slp_analyze_operations (bb_vinfo))
{
if (vect_print_dump_info (REPORT_UNVECTORIZED_LOCATIONS))
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
|| ! offsettable_memref_p (reg_equiv_mem (regno))
^^^ here
> - || num_not_at_initial_offset
to fail, which should cause find_reloads_subreg_address to get called.
Why is that not happening for you?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
s how to fix this? Should tail merging detect
__builtin_unreachable and not merge such block? Or else, should
the CFG optimizer be extended (how?) to handle unreachable blocks
with multiple predecessors better?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
2012-02-22 12:22:43 +
+++ gcc/combine.c 2012-07-03 19:46:18 +
@@ -8432,6 +8432,7 @@
in OP_MODE. */
if (CONST_INT_P (XEXP (x, 1))
+ && INTVAL (XEXP (x, 1)) >= 0
&& INTVAL (XEXP (x, 1)) < HOST_BITS_PER_WIDE_INT
&& HWI
er BUILT_IN_UNREACHABLE.
>
> * gcc.dg/builtin-unreachable-6.c: New test.
> * gcc.dg/builtin-unreachable-5.c: New test.
Many thanks for taking care of this!
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
tch"
[(set (match_operand:QHSD 0 "s_register_operand" "=&r")
--- 307,314
arm_split_atomic_op (, NULL, operands[0], operands[1],
operands[2], operands[3], operands[4]);
DONE;
! }
! [(set_attr "length" "")])
(define_insn_and_split "atomic_nand_fetch"
[(set (match_operand:QHSD 0 "s_register_operand" "=&r")
***
*** 315,321
arm_split_atomic_op (NOT, NULL, operands[0], operands[1],
operands[2], operands[3], operands[4]);
DONE;
! })
(define_insn "arm_load_exclusive"
[(set (match_operand:SI 0 "s_register_operand" "=r")
--- 331,338
arm_split_atomic_op (NOT, NULL, operands[0], operands[1],
operands[2], operands[3], operands[4]);
DONE;
! }
! [(set_attr "length" "")])
(define_insn "arm_load_exclusive"
[(set (match_operand:SI 0 "s_register_operand" "=r")
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
FOR_EACH_EDGE (e, ei, bb->preds)
{
gsi = gsi_last_bb (e->src);
! if (gsi_end_p (gsi))
! continue;
! stmt = gsi_stmt (gsi);
! if (gimple_code (stmt) == GIMPLE_COND)
{
if (e->flags & EDGE_TRUE_VALUE)
gimple_cond_make_false (stmt);
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
SM_CAN_OUTPUT_MI_THUNK
hook_bool_const_tree_hwi_hwi_const_tree_true
+
+ /* Variable tracking should be run after all optimizations which
+change order of insns. It also needs a valid CFG. */
+ #undef TARGET_DELAY_VARTRACK
+ #define TARGET_DELAY_VARTRACK true
+
+ struct gcc_target targetm = TARGET_INITIALIZER;
+
#include "gt-spu.h"
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
tribute -- if we do the change you suggest, I guess we
should then also remove those attributes?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Earnshaw wrote:
> On 17/07/12 16:17, Ulrich Weigand wrote:
> > Richard Earnshaw wrote:
> >
> >> Hmm, I wonder if we should just unconditionally call split_all_insns()
> >> at the start of md_reorg when -O0. This would address your problem, but
> >&
izing, all insns have already
+ been split at this point. */
+ if (!optimize)
+ split_all_insns_noflow ();
+
minipool_fix_head = minipool_fix_tail = NULL;
/* The first insn must always be a note, or the code below won't
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Earnshaw wrote:
> On 23/07/12 14:57, Ulrich Weigand wrote:
> > * config/arm/arm.c (arm_reorg): Ensure all insns are split.
> OK.
Checked in now. Is this OK for 4.7 as well?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
address will exactly correspond to
> misalignment when masking off and applying to a vector. And,
> you may have to conditionalize some vectorizer tests with the
> effective-target unaligned_stack.
I *think* this ought to work out OK, since the realignment scheme
consults the type alignment:
new_st
quot; } } */
--- 56,60 ----
/* { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect" } } */
/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0
"vect" } } */
! /* { dg-final { scan-tree-dump-times "Alignment of access forced using
peeling" 2 "vect" { xfail { vect_no_align || { ! vect_natural_alignment } } } }
} */
/* { dg-final { cleanup-tree-dump "vect" } } */
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
lete_output_reload can see it. */
! if (replace_reloads && recog_data.operand[opnum] != x)
! /* We mark the USE with QImode so that we recognize it as one that
!can be safely deleted at the end of reload. */
! PUT_MODE (emit_insn_before (gen_rtx_USE (VOIDmode, SUBREG_REG (x)), insn),
! QImode);
if (address_reloaded)
*address_reloaded = reloaded;
! return tem;
}
/* Substitute into the current INSN the registers into which we have reloaded
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ROL
(LCTLG), STORE CHARACTERS UNDER MASK,
and STORE CONTROL (STCTG) access their storage
operands in a left-to-right direction, and all bytes
accessed within each doubleword appear to be
accessed concurrently as observed by other CPUs. ]
Otherwise the patch looks good to me.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Guenther wrote:
> On Fri, Jul 27, 2012 at 5:24 PM, Ulrich Weigand wrote:
> > OK for mainline?
>
> Ok. Please add to the documentation that the default vector alignment
> has to be a power-of-two multiple of the default vector element alignment.
Committed, thanks. The
Richard Henderson wrote:
> On 2012-07-30 07:09, Ulrich Weigand wrote:
> > This seems to disable use of ICM / STCM to perform byte or
> > aligned halfword access. Why is this necessary? Those operations
> > are supposed to provide the required operand consistency ...
>
o a RISBG. I guess the point of the
RISBG is that you can avoid the extra shift ... Now, if that shift
can be moved ahead of the loop, that may not be all that big of a
win. On the other hand, these loops hopefully don't loop very often
if we don't have a lot of contention ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
x27;ll have a look what's going on here.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
> - cmpv = force_reg (SImode, val);
> - store_bit_field (cmpv, GET_MODE_BITSIZE (mode), 0,
> -0, 0, SImode, cmp);
> + cc = s390_emit_compare_and_swap (NE, res, ac.memsi, cmpv, newv);
> + emit_insn (gen_cstorecc4 (btarget, cc, XEXP (cc, 0), XEXP (cc, 1)));
> }
... and here.
This fixes the main atomic test failures I was seeing. I've restarted
the full bootstrap / regression test now ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
nd expand_insv needs to be
called with bitpos 0 (due to bits-big-endian).
When reverting this part of your patch (and together with the EQ/NE fix
pointed out here: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00170.html),
I can complete a bootstrap/testing cycle without regressions.
(There's still code being generated that looks a bit inefficient, but that's
a different story.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
register is always
equivalent to the memory so the substitution is valid even if there
are intervening stores. Also, don't move a volatile asm or
UNSPEC_VOLATILE across any other insns. */
|| (! all_adjacent
&& (((!MEM_P (src)
|| ! find_reg_note (insn, REG_EQUIV, src))
&& use_crosses_set_p (src, DF_INSN_LUID (insn)))
|| (GET_CODE (src) == ASM_OPERANDS && MEM_VOLATILE_P (src))
|| GET_CODE (src) == UNSPEC_VOLATILE))
Note that we have exactly the case mentioned, where a series of instructions
to be combined all set the same (CC) register. If they're all adjacent,
this still gets optimized away -- but they no longer are due to the store.
Is there a way of structuring the atomic optabs/expander so that the store
gets done either before or after all the CC operations?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
AX (max_cost_classes_num,
regno_cost_classes[ALLOCNO_REGNO (a)]->num);
since reg_preferred_class returns 255 for the new pseudo.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
eturn NULL;
+ if (!vect_same_loop_or_bb_p (last_stmt, use_stmt))
+ return NULL;
+
use_lhs = gimple_assign_lhs (use_stmt);
use_type = TREE_TYPE (use_lhs);
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
, use_stmt))
- return NULL;
-
use_lhs = gimple_assign_lhs (use_stmt);
use_type = TREE_TYPE (use_lhs);
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
reload register of current one
> with type
> RELOAD_FOR_INPADDR_ADDRESS.
This is OK. (You also ought to mention the RELOAD_FOR_OUTADDR_ADDRESS
part of the change in the ChangeLog.)
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Bernd Schmidt wrote:
> On 04/27/2012 06:25 PM, Ulrich Weigand wrote:
> > Bernd Schmidt wrote:
> >
> >> We're creating new pseudos, and while we're resizing some data
> >> structures, we aren't doing it for everything.
> >
Richard Sandiford wrote:
> "Ulrich Weigand" writes:
> > Richard Sandiford wrote:
> >> Vladimir Makarov writes:
> >> > Taking your results for S390 and ARM with Neon into account, I guess it
> >> > should be included and probably made by de
Bin Cheng wrote:
> Thanks for reviewing, I modified the ChangeLog. Is it ok for trunk and 4.7?
Yes, this is OK for trunk.
Once it has been in trunk for a week or so and nobody reported any regressions,
it would also be OK to backport to 4.7.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
Richard Guenther wrote:
> On Mon, Apr 30, 2012 at 6:19 PM, Ulrich Weigand wrote:
> > Hello,
> >
> > as a second step in refactoring this patch introduces a routine
> > vect_find_single_use to determine whether a defining statement
> > has one single use within
Richard Guenther wrote:
> On Tue, 24 Apr 2012, Ulrich Weigand wrote:
> > However, even so, it might actually be preferable to just handle such
> > cases within vect_recog_widen_shift_pattern itself. Indeed, the routine
> > already looks for another subsequent type cas
breakage. Yes, that was clearly a merge error
when adapting the patch to 4.7 (in 4.7, tree-vect-patterns.c does not
yet support SLP, which means some of the tests needed to be modified).
You fix looks correct to me; thanks for looking into this!
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Guenther wrote:
> On Thu, Mar 8, 2012 at 3:29 PM, Ulrich Weigand wrote:
> > - Should I try to improve forwprop to handle casts and additional re-
> > association cases until it handles the above expression?
>
> Yes, ideally by trying to sub-divide this task int
Richard Guenther wrote:
> On Fri, May 18, 2012 at 10:27 PM, Ulrich Weigand wrote:
> > The following patch rewrites associate_plusminus to remove all the
> > explicitly coded special cases, and instead performs a scan of the
> > plus/minus tree similar to what is done in tree-
really have to search the full solution space or back-track
an already performed expansion. I have not implemented this due
to concerns about combinatorial explosion ...
Solving this problem in the context of the existing tree-ssa-reassoc
algorithm is indeed yet another issue that I need to think about.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
orithm by number instead of symbolic name
doesn't look like much of an improvement to me :-)
But if the consensus is to go that way, the s390 bits are certainly
OK with me.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
nded to impose requirements on target's
restore_stack_block implemtations? What exactly are those
supposed to be?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Henderson wrote on 08/03/2011 04:15:26 PM:
> On 08/03/2011 07:07 AM, Ulrich Weigand wrote:
> > Was this assert intended to impose requirements on target's
> > restore_stack_block implemtations? What exactly are those
> > supposed to be?
>
> The a
ld indeed have not really been appropriate). Not sure why
those are getting built ... that's probably just for historical reasons.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
porary; that's up to the target to
implement.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
st be folded. */
+ double __attribute__((used))
+ sqrt (double x)
+ {
+ return x;
+ }
+
int main() { return 0; }
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Michael Matz wrote:
> Hi,
>
> On Tue, 26 Jul 2011, Michael Matz wrote:
>
> > On Tue, 26 Jul 2011, Michael Matz wrote:
> >
> > > Hi,
> > >
> > > On Tue, 26 Jul 2011, Ulrich Weigand wrote:
> > >
> > > > > Well, REG_ATTR
Richard Guenther wrote:
> On Mon, 8 Aug 2011, Ulrich Weigand wrote:
> > OK, so what about the following version? This keeps not linking against
> > libm so it will fail if cabs is not folded. On the other hand, it will
> > provide a dummy implementation of sqrt to avoid f
ot; } */
extern int a, *b;
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
(working copy)
***
*** 1,4
--- 1,5
! { dg-do run }
+ ! { dg-skip-if "Too big for local store" { spu-*-* } { "*" } { "" } }
! Check that we can open more than 26 scratch files concurrently
integer :: i
do i = 1, 30
--
Dr. Ulrich Weigan
just because there *is* a COMPONENT_REF around it, we suddenly
realize the fact that don't have points-to information for the MEM_REF
and therefore consider *it* (and consequently the whole COMPONENT_REF)
to be potentially misaligned ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
\
+ { \
+ (AD) = new_rtx; \
+ goto WIN;
\
+ } \
+ } while (0)
+
/* Costs */
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
/* Don't need to set a register with the result when we are
comparing against zero and branching. */
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Henderson wrote:
> On 08/16/2011 11:35 AM, Ulrich Weigand wrote:
> > + /* Reload the displacement. */
> > + push_reload (XEXP (ad, 1), NULL_RTX, &XEXP (ad, 1), NULL,
> > + BASE_REG_CLASS, GET_MODE (ad), VOIDmode, 0, 0,
> > +
zation
step and doesn't change that the endian flags remain well-defined ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
k: expected
ssa_name, have integer_cst in set_cond_stmt_execution_predicate, at
ipa-inline-analysis.c:1190
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
nch), I guess we don't really need any PR now ...
If you'd prefer to still have one, let me know and I'll
create it.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
opnum, (enum reload_type) type);
+ return true;
+}
+
+ if (GET_CODE (*p) == PLUS
&& GET_CODE (XEXP (*p, 0)) == REG
&& ARM_REGNO_OK_FOR_BASE_P (REGNO (XEXP (*p, 0)))
+ /* If the base register is equivalent to a constant, let the generic
+ code handl
is isn't true in your case?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Earnshaw wrote:
> On 19/09/11 15:14, Ulrich Weigand wrote:
> > So it seems to me that for match_operator operands, the
> > goal_alternative_win flag should always be true ...
> >
> > Can you find out why this isn't true in your case?
>
> H
: New testcase.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Michael Hope wrote:
> On Sat, Sep 10, 2011 at 5:04 AM, Ulrich Weigand wrote:
> > the problem in PR 50305 turned out to be caused by the ARM back-end
> > LEGITIMIZE_RELOAD_ADDRESS implementation.
>
> Interesting the fault goes away with -mfpu=neon, perhaps due to the DI
>
Ramana Radhakrishnan wrote:
> On 9 September 2011 18:04, Ulrich Weigand wrote:
> >
> > In theory, LEGITIMIZE_RELOAD_ADDRESS could attempt to handle them by
> > substituting the equivalent constant and then reloading the result.
> > However, this might need addit
Ramana Radhakrishnan wrote:
> On 26 September 2011 15:24, Ulrich Weigand wrote:
> > Is this sufficient, or should I test any other set of options as well?
>
> Could you run one set of tests with neon ?
Sorry for the delay, but I had to switch to my IGEP board for Neon
support, a
Richard Guenther wrote:
> On Tue, Feb 28, 2012 at 4:10 PM, Ulrich Weigand wrote:
> > I'll still need to do proper testing and benchmarking, but I thought
> > I'd post the patch anyway just as a heads-up ...
> >
> > Does this look reasonable to you?
>
>
ng on powerpc64-linux
with no regressions, and there are (as expected) no significant
changes in PowerPC benchmark results either.
OK to commit the two patches to mainline?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Guenther wrote:
> On Thu, Mar 8, 2012 at 3:56 PM, Ulrich Weigand wrote:
> > Ira Rosen posted a couple of vectorizer patches intended for 4.8:
> >
> > =A0 http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00191.html
> > =A0 http://gcc.gnu.org/ml/gcc-patches/2012-
Richard Guenter wrote:
> On Thu, Mar 8, 2012 at 3:29 PM, Ulrich Weigand wrote:
> > I'm wondering where to go from there:
> >
> > - Why are those special re-association cases handled only in forwprop,
> > and not in fold-cost? I would have expected forwprop to ju
new_rtx))
+ && (GET_MODE_SIZE (mode)
+ <= GET_MODE_SIZE (GET_MODE (SUBREG_REG (new_rtx))
flags |= PR_CAN_APPEAR;
if (!for_each_rtx (&new_rtx, varying_mem_p, NULL))
flags |= PR_HANDLE_MEM;
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ple_assign_rhs_code (stmt) == WIDEN_LSHIFT_EXPR
|| gimple_assign_rhs_code (stmt) == FLOAT_EXPR))
{
tree rhs_type = TREE_TYPE (gimple_assign_rhs1 (stmt));
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
letely: I understand that this UNSPEC is
simply a magic marker to make the address use the fs: or gs:
segment override, right? Now that GCC supports address spaces,
it might be possible to model fs:/gs: relative addresses instead
by using a non-standard address space ...
Bye,
Ulrich
--
Dr. U
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01269.html
Ping.
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
size == 32 && (align % 32) == 0)
align_bits = 256;
else if ((memsize == 16 || memsize == 32) && (align % 16) == 0)
align_bits = 128;
else if (memsize >= 8 && (align % 8) == 0)
align_bits = 64;
else
align_bits = 0;
B
use_lhs = gimple_assign_lhs (use_stmt);
use_type = TREE_TYPE (use_lhs);
if (!INTEGRAL_TYPE_P (use_type)
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
anks, Ramana! I've checked in the following patch.
Bye,
Ulrich
2012-04-16 Ulrich Weigand
* config/arm/arm.c (arm_print_operand): Fix invalid alignment
hints for 'A' operand types.
=== modified file 'gcc/config/arm/arm.c'
--- gcc/config/arm/arm.c
suming there are no priorities like ! or ? specified
in the .md file. Those would override in either case.)
Could you explain in more detail the problem you see with that?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
lified MEM would require first loading the segment part into a
(free) segment register, and then using that register to perform the
access ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ssion beyond usual noise levels.
Given that, and the impressive improvements we saw on some ARM benchmarks
involving vector code (up to 70%), it would really be a pity to see the
patch going nowhere ...
Is there anything we can do to help make the patch more acceptable?
Any suggestions welcome ...
tions strictly match insn patterns;
it is not something that any other pass will do on its own ...
In particular, constrain_operands does not (and is not supposed to)
perform any modification of the input pattern, it just checks whether
the pattern as-is validly matches an alternative.
Bye,
Ulrich
handle such
cases within vect_recog_widen_shift_pattern itself. Indeed, the routine
already looks for another subsequent type cast, in order to handle
unsigned shift variants. Maybe it simply ought to always look for
another cast, and detect over-widening situations itself?
Does this look reasonable? Any comments or suggestions appreciated!
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ork with Ramana to enable it on ARM where it makes sense,
probably when targeting Cortex-A cores.)
Thanks again to you and Vlad for looking into this long-standing problem!
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
fix-over-widening-*and*-
use-widening-shift effect ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Guenther wrote:
> On Tue, 24 Apr 2012, Ulrich Weigand wrote:
> > Does this look reasonable? Any comments or suggestions appreciated!
>
> Yes, getting rid of this fragile interaction by doing more work in
> vect_recog_widen_shift_pattern sounds like the correct thing to
Andreas Krebbel wrote:
> 2011-11-17 Andreas Krebbel
>
> * reload.c (find_reloads): Change the loop nesting when trying an
> alternative with swapped operands.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ler supports /* ... */
comments. But this isn't really necessary for the test to work; I think the
best fix would be to just remove the comment and simply write
__asm__ volatile ("" : : "nro" (e1), "nro" (e2), "nro" (e3 ...
instead.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Mike Stump wrote:
> On Nov 18, 2011, at 9:04 AM, "Ulrich Weigand" wrote:
> > Huh, it seems the test in this form assumes the assembler supports /* ...
> > */
> > comments. But this isn't really necessary for the test to work; I think the
> > best f
n ... Do you have
any suggestions on how to fix this? If we add the fwprop patch,
should we then disable apply_distributive_law for SUBREGs?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
uld provide any benefit.
Maybe the best solution would be to remove the SUBREG case from the generic
apply_distributive_law subroutine, and instead add a special check for the
distributed subreg case right at the above place in simplify_set; i.e. to
perform the inverse distribution only if it is already guaranteed that we
will also be able to move the subreg to the LHS ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
(x),
-gen_lowpart (GET_MODE (SUBREG_REG (src)),
- dest));
- SUBST (SET_SRC (x), SUBREG_REG (src));
+ SUBST (SET_DEST (x), gen_lowpart (GET_MODE (src_subreg), dest));
+ SUBST (SET_SRC (x), src_subreg);
src = SET_SRC (x), dest = SET_DEST
epub3/chunk.xsl...
> configure: error: cannot check for file existence when cross compiling
> make[1]: *** [configure-target-libstdc++-v3] Error 1
> make[1]: Leaving directory `/tmp/hpautotest-gcc1/cris-elf/gccobj'
> make: *** [all] Error 2
Yes, I'm seeing the same problem whe
aded = 1;
>
> return x;
> }
> --- 6232,6238
> }
> }
> if (reloaded && address_reloaded)
> ! *address_reloaded = reloaded;
I think this would be even better if written as
if (address_reloaded)
*address_reloaded = reloaded;
Otherwise
C is most likely going to be
replaced by some reload register (note that emit_reload_insns is
called *before* subst_reloads), which makes it really unclear how
valid it is to use the original value of SET_SRC before substitution ...
Maybe the conservative fix would be to not handle case [A], and neither
case [B] when the register does not reach the end. Not sure if this
would show up as performance regression somewhere, but it seems unlikely
to me.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Sandiford wrote:
> "Ulrich Weigand" writes:
> > Richard Sandiford wrote:
> >> Either way, the idea is that new_spill_reg_store[R] is only valid
> >> for reload registers R that reach the end of the reload sequence.
> >> We real
ng the change
above causes the attribute to be honored again.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
n_sets_and_refs ();
ira_set_pseudo_classes (sched_verbose ? sched_dump : NULL);
+ regstat_free_n_sets_and_refs ();
sched_regno_pressure_class
= (enum reg_class *) xmalloc (max_regno * sizeof (enum reg_class));
for (i = 0; i < max_regno; i++)
--
Dr. Ulrich Weigand
GNU Toolchain for Lin
Vladimir Makarov wrote:
> On 02/14/2012 12:00 PM, Ulrich Weigand wrote:
> > This is fixed by the following patch. However, I'm not quite sure if this
> > is
> > the best way to fix the problem, given that the REG_N_REFS use occurs only
> > for
> > debug ou
x86_64-*-*] } {
+|| [istarget x86_64-*-*]
+|| ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]) }
{
set et_vect_cond_saved 1
}
}
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
or example, I guess GCC configury could rename its instance of
HAVE_INITFINI_ARRAY (maybe define USE_INITFINI_ARRAY to begin
with)?
Any suggestions how to proceed with this welcome! I'd really
like to see this fixed for 4.7, otherwise the compiler will be
seriously broken ...
Thanks,
Ulrich
--
D
Jakub Jelinek wrote:
> On Wed, Feb 22, 2012 at 03:55:34PM +0100, Ulrich Weigand wrote:
> > However, the macro HAVE_INITFINI_ARRAY is defined anyway; this
> > definition is done by an internal "newlib.h" header that is pulled
> > in via the include in GCC's &
xplicit_realign_optimized;
Should this now also use STMT_VINFO_DR_STEP?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Guenther wrote:
> On Thu, 23 Feb 2012, Ulrich Weigand wrote:
> > The assert in question looks like:
> >
> > if (nested_in_vect_loop
> > && (TREE_INT_CST_LOW (STMT_VINFO_DR_STEP (stmt_info))
> > % GET_MODE_SIZE (TYPE_MODE (vectype
(""), __builtin_inff(),
float, comparecf);
+ #endif
}
void
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Guenther wrote:
> On Fri, Feb 24, 2012 at 2:16 PM, Ulrich Weigand wrote:
> > this looks to me that, since the check is intended to verify that
> > "misalignment remains the same throughout the execuction of the loop",
> > we actually want to check the in
301 - 400 of 480 matches
Mail list logo
