Andreas Krebbel wrote:
>gcc/ChangeLog:
>PR target/102024
>* config/s390/s390-protos.h (s390_function_arg_vector): Remove
>prototype.
>* config/s390/s390.cc (s390_single_field_struct_p): New
function.
>(s390_function_arg_vector): Invoke s390_single_field_str
On Thu, Mar 25, 2021 at 12:21:42PM -0500, will schmidt wrote:
> On Wed, 2021-03-10 at 18:50 +0100, Ulrich Weigand wrote:
> > Will Schmidt wrote:
> >
> > > This is a patch written by Alan Modra. With his permission
> > > I'm submitting this fo
Is this
> always true? */
No, it could be either way. But it shouldn't really matter since
you just need to apply the same displaced offset to the target,
whether the offset is positive or negative. Again, you should
just do it the same way it is already done by existing code
that ha
ors you're seeing, it would
probably be OK to go with just this minimal change -- unless we can
just move to LRA as mentioned above.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
her
with fast-math or no-fast-math is excess-precision=fast, so again
it should not be touched.
I'll still need to look into the language-specific handling of the
excess precision setting to make sure this works for all languages.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
On Sat, Nov 21, 2020 at 01:57:32PM -0600, Segher Boessenkool wrote:
> On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote:
> > On 2/11/20 11:43 AM, Ulrich Weigand wrote:
> > > 1. If a component flag of -ffast-math (or -funsafe-math-optimizations)
> > >is expli
get clarity here as I'm about to work on this
for clang ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
te_math_only
- && !opts->x_flag_signed_zeros
&& !opts->x_flag_errno_math
+ && !opts->x_flag_rounding_math
+ && opts->x_flag_cx_limited_range
&& opts->x_flag_excess_precision == EXCESS_PRECISION_FAST);
}
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Joseph Myers wrote:
> On Mon, 10 Feb 2020, Ulrich Weigand wrote:
> > I'm not sure how this can be implemented in the current option handling
> > framework. The -ffast-math handling case would have to check whether
> > or not there is any explicit use of -f(no-)finite-m
Segher Boessenkool wrote:
> On Fri, Feb 07, 2020 at 05:47:32PM +0100, Ulrich Weigand wrote:
> > > but what happens to -fsignalling-nans -ffast-math then? Better leave
> > > those
> > > in I'd say.
> >
> > Ah, it seems I was confused about the int
Joseph Myers wrote:
> On Fri, 7 Feb 2020, Ulrich Weigand wrote:
>
> > I thought that a *more specific* option like -fsignalling-nans was always
> > intended to override a more generic option like -ffast-math, no matter
> > whether it comes before or after it on the comman
Richard Biener wrote:
> On Fri, Jan 31, 2020 at 6:01 PM Ulrich Weigand wrote:
> > The overall effect of this patch is that now all component flags of
> > -ffast-math are treated exactly equivalently:
> > * they are set (changed from their default) with -ffast-math
>
th
&& opts->x_flag_unsafe_math_optimizations
&& opts->x_flag_finite_math_only
- && !opts->x_flag_signed_zeros
&& !opts->x_flag_errno_math
+ && opts->x_flag_cx_limited_range
&& opts->x_flag_excess_precision == EXCESS_PRECISION_FAST);
}
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
ain listed with other roles.
Ah, you're right -- thanks for catching this!
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Richard Biener wrote:
> On Fri, Sep 6, 2019 at 3:00 PM Ulrich Weigand wrote:
> > But as far as I can see, for *atomic* operations at least, we do make
> > that assumption. The x86 back-end for example just assumes that any
> > "int" or "long" object tha
Richard Biener wrote:
> On Tue, Sep 3, 2019 at 3:09 PM Ulrich Weigand wrote:
> > > If you read the C standards fine-print then yes. But people (or
> > > even the C frontend!) hardly get that correct since for example
> > > for
> > >
> >
Richard Biener wrote:
> On Tue, Sep 3, 2019 at 1:56 PM Ulrich Weigand wrote:
> > combined with the fact that get_object_alignment_2 actually itself
> > uses type alignment if we have an actual memory object:
> > /* When EXP is an actual memory refe
Richard Biener wrote:
> On Mon, Sep 2, 2019 at 10:35 PM Ulrich Weigand wrote:
> > Now one question might be, why does get_pointer_alignment not take
> > type alignment into account by itself? This appears to be deliberate
> > to avoid considering numeric pointer values to
- __int128 lock;
+ aligned_int128 lock;
__int128 rval;
lock = oval;
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
__eaa * (__c2 - __pndev * __c3)
+ _Tp __s3 = __pndev * __ea * (__c2 - __pndev * __c3)
- __c2 * __pndev * __ec;
return _Tp(3) * __sigma + __power4 * (__s1 + __s2 + __s3)
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
[RFA][2/3] Remove Cell Broadband Engine SPU targets: testsuite
Remove all references to spu from the testsuite directory.
Tested on s390x-ibm-linux.
OK for mainline?
(Deleted directories omitted from patch.)
Bye,
Ulrich
gcc/testsuite/ChangeLog:
* lib/compat.exp: Remove references t
Oleg Endo
sparc port David S. Miller
sparc port Eric Botcazou
-spu port Trevor Smigiel
-spu port David Edelsohn
-spu port Ulrich Weigand
tilegx port
Eric Gallagher wrote:
> On 4/2/19, Ulrich Weigand wrote:
> > Hello,
> >
> > the spu-elf target in GCC supports generating code for the SPU processors
> > of the Cell Broadband Engine; it has been part of upstream GCC since 2008.
> >
> > However, at this poin
cc.gnu.org/ml/gcc/2018-10/msg00139.html";>
announcement.
+
+ Cell Broadband Engine SPU (spu*-*-*). Details can be
found
+ in the https://gcc.gnu.org/ml/gcc/2019-04/msg00023.html";>
+ announcement.
+
--
Dr. Ulrich Weigand
GNU/
)
if test "x$enable_obsolete" != xyes; then
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
testsuite/ChangeLog:
>
> 2019-02-11 Ilya Leoshkevich
>
> PR target/89233
> * gcc.target/s390/pr89233.c: New test.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
because they do not use a base
register. */
static void
annotate_constant_pool_refs (rtx_insn *insn)
{
if (s390_safe_relative_long_p (insn))
return;
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
les. I think this is a
> reasonable way to deal with architecutral differences without making
> inliner hard to tune in long term.
Thanks for the heads-up! This looks interesting, we'll have a look.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
t; +extensions (e.g., by using @code{-std=c11}) and including
> +@code{}.
> +@end itemize
This looks correct to me, and I've just verified that the example
does indeed build with -std=c11 and #include and fails
to build without either of these.
Bye,
Ulrich
--
Dr. Ulrich We
ot* switch to keyword-and-
predefine mode, as far as I can tell. Rather, to switch to that mode
you'll have to disable GNU extensions, e.g. via -std=c11, and then
include to get the predefine.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
.com/epubs/pdf/dz9ar008.pdf";>ESA/390
Principles of Operation
http://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_zSeries.html";>Linux for
z Systems ABI
+ http://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_s390.html";>Linux for
S/390 ABI
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
): Likewise.
> (s390_emit_prologue): Likewise.
> (s390_emit_epilogue): Likewise.
This version is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
) || CALL_P (insn))
&& !s390_safe_relative_long_p (insn))
(This last change is just a suggestion, only if it makes the
overall code simpler and more readable.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
P_IN_RANGE (INTVAL (frame_off)))
> {
> - insn = gen_rtx_SET (frame_pointer,
> - gen_rtx_PLUS (Pmode, frame_pointer, frame_off));
> - insn = emit_insn (insn);
> + insn = emit_insn (copy_rtx (cfa));
> }
This seems unrelated?
Bye,
Ulrich
--
Ilya Leoshkevich wrote:
> Am 30.10.2018 um 18:22 schrieb Ulrich Weigand :
> > This definitely looks wrong. If we haven't annotated the address,
> > it should *not* be found by find_constant_pool_ref, since we are
> > not going to replace it! That was the whole point o
re
not going to replace it! That was the whole point of not annotating
it in the first place ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Ilya Leoshkevich wrote:
> Am 30.10.2018 um 16:20 schrieb Ulrich Weigand :
> > Not sure that this is fully correct either. *Some* instructions, like
> > e.g. floating-point loads, do not accept relative operands. And even
> > for the relative loads that exist, there may
Ilya Leoshkevich wrote:
> Am 29.10.2018 um 19:45 schrieb Ulrich Weigand :
>
> > This is true. But something else must still be going on here. Note that
> > many other instruction patterns might contain constant pool addresses,
> > since they are accepted e.g. by the &#
ontains a register reference, so it shouldn't
really be CONST. (And if it were, why make the change just here and not
everywhere a UNSPEC_LTREF is generated?)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
> 2018-09-19 Ilya Leoshkevich
>
> PR target/80080
> * gcc.target/s390/risbg-ll-3.c: Expect conditional returns.
> * gcc.target/s390/zvector/vec-cmp-2.c: Likewise.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
_emit_epilogue as above,
this point is moot; you don't even need to generate a REG RTX
if it's for r14 then.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
n
Yes, exactly ... this commit introduced the regression.
> OK, I've regressed the branches then - I'll fix that.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
assume aligned_alloc
is not available, but then the new_opc.cc file tries to define its own
version, conflicting with the newlib prototype that is actually there.
So one way or the other this needs to be fixed ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Since branch splitting is gone, this whole logic is superfluous;
the loop will never execute more than once. (It may not be
necessary any longer to split the logic into the various
chunkify_start/finish routines either ...)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers a
TARGET_CONSTANT_ALIGNMENT
#define TARGET_CONSTANT_ALIGNMENT spu_constant_alignment
+#undef TARGET_HAVE_SPECULATION_SAFE_VALUE
+#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-spu.h"
--
Dr. Ulrich Weigand
ibgfortran on spu, and presumably
> any platform that uses gthr-simple instead of gthr-posix.
The file is called gthr-single.h, not gthr-simple.h ... sorry for the typo.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
features provided in gthr-simple.h as well.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
or addr.indx, since s390_decompose_address will never fill in
*just* an index.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
if (INSN_P (insn) && INSN_CODE (insn) == CODE_FOR_blockage && next_insn)
{
if (GET_MODE (insn) == TImode)
PUT_MODE (next_insn, TImode);
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
symref memory operands. Remove CC mode and call s390_match_ccmode
> instead.
> ("atomic_exchange"): Allow and implement all integer modes.
>
> gcc/testsuite/ChangeLog-dv-atomic-gcc7
>
> * gcc.target/s390/md/atomic_compare_exchange-1.c: New tes
t stage1.
Andreas, do you have an opinion on this?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Dominik Vogt wrote:
> On Fri, Apr 07, 2017 at 04:34:44PM +0200, Ulrich Weigand wrote:
> > > +; Peephole to combine a load-and-test from volatile memory which combine
> > > does
> > > +; not do.
> > > +(define_peephole2
> > >
of the CS changes now
actually *rely* on this change to cstorecc4 ... s390_expand_cs_tdsi only
calls cstorecc4 on !TARGET_Z196, where the above change is a no-op, and
in the TARGET_Z196 case it deliberates does *not* use cstorecc4.
Now, in general this improvement to cstorecc4 is of course valuable
in itself. But I think at this point it might be better to separate
this out into an independent patch (and measure its effect separately).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
you're just emitting RTL directly, maybe you could simply use
> the expander pattern above to do so (and not use emit_insn followed
> by DONE in this case?)
Therefore this doesn't work either.
Sorry for the confusion.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Dominik Vogt wrote:
> > v3:
> >
> > * Remove sne* patterns.
> > * Move alignment check from s390_expand_cs to s390.md.
> > * Use s_operand instead of memory_nosymref_operand.
> > * Remove memory_nosymref_operand.
> > * Allow any CC-mode in cstorecc4 for TARGET_Z196.
> > * Fix EQ with
s fix
> > most of the problems reported in PR 80080:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080
> >
> > Bootstrapped and regression tested on a zEC12 with s390 and s390x
> > biarch.
>
> New version attached.
No, it isn't :-)
Bye,
Ulrich
--
Dr. Ul
and VSX modes don't allow them) or is a pre-increment or decrement.
On the other hand, for addresses based on a virtual register,
legitimate_address_p does not depend on the mode since those
are special-cased to be always accepted (see the discussion above).
So I'm not sure that th
(spu_legitimate_address_p): Fix logic error and add missing fallthru
> comment.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
lrich Weigand
s390 port Andreas Krebbel
score port Chen Liqin
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
* gcc.c-torture/compile/pr72771.c: New.
Yes, this makes sense. address_reloaded == -1 means that the address
may or may not have been fully reloaded, so we always need to take the
conservative action in that case.
The patch is OK.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and
Alan Modra wrote:
> On Tue, Jul 12, 2016 at 02:02:43PM +0200, Ulrich Weigand wrote:
> > The second time around, get_secondary_mem should reuse the
> > same stack slot it already allocated, and the elimination
> > offsets should already be set to accommodate that stack slot
Alan Modra wrote:
> On Mon, Jul 11, 2016 at 03:26:46PM +0200, Ulrich Weigand wrote:
> > However, there still seems to be another underlying problem: reload
> > should never generate invalid instructions. (Playing with '?' to
> > fix *inefficient* instructions is
a to investigate
why that isn't happening in this test case. [ There is a chance that
the underlying bug will reappear in a different context, even after
the '?' change is applied. ]
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
David Malcolm wrote:
> On Mon, 2016-06-13 at 13:36 +0200, Ulrich Weigand wrote:
> > Gerald Pfeifer wrote:
> >
> > > The source code of need_finalization_p in ggc.h reads
> > >
> > >template
> > >static inline bool
> > >
t;#endif
>}
>
> which means your self test is broken by design for any compiler
> that is not GCC in at least version 4.3, isn't it?
Just to confirm that I'm seeing the same failure on my SPU
daily build machine, which is running RHEL 5 with a host
compiler of GCC
Andre Vieira (lists) wrote:
> On 07/04/16 10:30, Andre Vieira (lists) wrote:
> > On 17/03/16 16:33, Andre Vieira (lists) wrote:
> >> On 23/10/15 12:31, Bernd Schmidt wrote:
> >>> On 10/12/2015 11:58 AM, Ulrich Weigand wrote:
> &g
y_to_reg (newval);
+
mem = rs6000_pre_atomic_barrier (mem, mod_s);
label1 = NULL_RTX;
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
size is nonzero)?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
0 "register_operand" "")
(unspec:V_HW [(match_operand: 1 "register_operand" "")
(match_operand:SI2
"shift_count_or_setmem_operand" "")
(match_dup 0)]
UNSPEC_VEC_SET))]
"TARGET_VX"
"")
Then the only remaining users of shift_count_or_setmem_operand are the
actual setmem patterns (so maybe the predicate can be renamed to
"setmem_operand") :-)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
e mail),
this all looks now very good to me.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
(plus:SI (match_operand:SI 2 "nonmemory_operand"
> "a, I")
> + (match_operand:SI 3 "const_int_operand"
> "n, I"))]
> +UNSPEC_VEC_EXTRACT))]
> + "TARGET_VX"
> + "@
> + vlgv\t%0,%v1,%3(%2)
> + vste\t%v1,%0,%2"
> + [(set_attr "op_type" "VRS,VRX")])
Likewise for %3. Also, the second alternative seems odd, it matches solely a
PLUS of two CONST_INTs, which is not canonical RTL ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
ops" "addr_style_op_subst" "%Y2" "%Y3(%2)")
and we don't need addr_style_op_enabled any more? %Y would continue
to emit both simple constants and register operands (and full address
operands e.g. for setmem) as before.
> +(define_subst "masked_op
something wrong in how GCC implements the AIX ABI. But I'm
not really familar with AIX, so I can't help much with that.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Alan Modra wrote:
> On Fri, Feb 12, 2016 at 02:57:22PM +0100, Ulrich Weigand wrote:
> > Right. It's a bit unfortunate that we can't just use IFmode
> > unconditionally,
> > but it seems rs6000_scalar_mode_supported_p (IFmode) may return false, and
> > t
is double double)
in any pair of registers where DFmode is allowed, since the type *is* just a
pair of DFmode values. Again, really more a stage 1 matter ...
> On Thu, Feb 11, 2016 at 07:38:15PM +0100, Ulrich Weigand wrote:
> > It's not a bug, it's deliberate behavior. The reloa
preted as V4SFmode when used as input to xscvspdpn, which
gets a DFmode output that is again silently re-interpreted as
SFmode.
This isn't really wrong as such, just maybe a bit confusing.
Maybe instead have p8_mtvsrd use DImode as output (instead of
DFmode), which shouldn't be any harder to us
t (match_operand:VM2 0 "register_operand" "=v")
> + (match_operand:VM2 1 "memory_operand" "Z"))
> + (unspec [(const_int 0)] UNSPEC_SET_VSCR)])]
> + "TARGET_ALTIVEC"
> + "lvx %0,%y1"
>[(set_attr "type" "vecload")])
now causes vec_ldl to emit the lvx instead of the lvxl instruction.
I assume this was not actually intended?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
be producing an error, instead of silently
> emitting code with unfixed prologue.
OK, fine with me. B.t.w. Andreas has checked in the sibcall fix,
so you no longer should be seeing larl used for sibcalls.
> I've updated and resubmitted the gold patch.
Thanks!
Bye,
Ulrich
--
Dr. Ulr
tg
brxh
brxhg
brxle
brxlg
crj
cgrj
clrj
clgrj
cij
cgij
clij
clgij
Note that those are *all* branch instructions, so it might
make sense to add any PC16DBL targetting a function symbol
to the list of calls, just in case. (But since basically
nobody ever uses -msmall-exec, it doesn't really matte
x that bug. That won't help for existing objects,
but those don't use split stack either, so that shouldn't matter.
If we fix that bug before (or at the same time as) adding split-stack
support, the linker will still be able to distigunish function pointer
loads from calls (including
Changes applied. Testsuite still running, still works on my simple tests.
>
> As for common code prerequisites: #3 is no longer needed, and very likely
> so is #4 (it fixes problems that I've only seen with ESA mode, and testsuite
> runs just fine without it now).
OK, I see
atch_operand 3 "consttable_operand" "X")]
And similarly here, just use const_int_operand.
Otherwise, this all looks very good to me.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
me* full stack check is generated as for any
other routine. Now I'm wondering: is there are reason why
this check would be necessary (and there's simply a bug in
the rs6000 implementation)? Then we obviously should do the
same on s390.
On the other hand, if rs6000 works fine *without* any code
in frameless routines, why wouldn't that work for s390 too?
Emitting a nop (that is always executed) still looks weird to me.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Andreas Krebbel wrote:
> On 02/01/2016 02:45 PM, Ulrich Weigand wrote:
> > So I'm wondering what the difference is between this and simply
> > overriding the default implementation of "enabled" per-insn?
> >
> > So instead of adding
> > (set_at
and 3 "const_int_operand" "n"))
if that is possible via the subst mechanism ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Andreas Krebbel wrote:
> On 02/01/2016 02:30 PM, Ulrich Weigand wrote:
> > This seems to add just a single alternative. Is that OK if it gets
> > substituted into a pattern that used multiple alternatives otherwise?
> Yes. This is supposed to work. The new constraint will b
Andreas Krebbel wrote:
> * config/s390/s390.c (s390_decompose_address): Don't accept SImode
> anymore.
Great! Very nice to finally get rid of this.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
nt 1)
>
> (and (eq_attr "cpu_facility" "ieee")
So I'm wondering what the difference is between this and simply
overriding the default implementation of "enabled" per-insn?
So instead of adding
(set_attr "disabled" "0,1")])
to an insn, you might simply add instead:
(set_attr "enabled" "*,0")])
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
t;shift_count_or_setmem_operand" "")
> + (subreg:SI (match_operand:TI 4 "register_operand" "")
> + 12)]
> + UNSPEC_REPLICATE_BYTE))
> + (use (match_operand:TI 1 "register_operand" ""))
> + (clobber (reg:CC CC_REGNUM))])
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
v")
> +(plus:SI (match_operand:SI 2 "register_operand"
> "a, I")
The second alternative can never match here, can it?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
+ "tabort\t%1(%0)"
This seems dangerous: const_int_operand may match a constant that does
not fit into the "J" constraint, which would lead to an abort in reload.
What is the semantics for the abort code anyway? It is supposed to be
automatically truncated or not?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
"setcc_subst"
> +; This adds an explicit CC reg set to an operation while dropping the
> +; result of the operation.
> +(define_subst "cconly_subst"
These are nice! It would seem they could be applied to simplify many
of the non-shift patterns too, right?
Bye
"n"])
This seems to add just a single alternative. Is that OK if it gets
substituted into a pattern that used multiple alternatives otherwise?
> +; In the subst pattern we have to disable the alternative where op2 is
> +; already a constant. This attribute is supposed to be used in the
> +; "disabled" insn attribute to achieve this.
> +(define_subst_attr "addr_style_op_disable" "addr_style_op_subst" "0" "1")
Is this necessary given that the subst adds a REG_P (operands[2])
condition?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Dominik Vogt wrote:
> On Wed, Dec 16, 2015 at 01:51:45PM +0100, Ulrich Weigand wrote:
> > Dominik Vogt wrote:
> > > > r2 through r4 should be fine. [ Not sure if there will be many (any?)
> > > > cases
> > > > where one of those is unused but r5 isn&
Dominik Vogt wrote:
> On Mon, Dec 14, 2015 at 04:08:32PM +0100, Ulrich Weigand wrote:
> > I don't think that r1 is actually safe here. Note that it may be used
> > (unconditionally) as temp register in s390_emit_prologue in certain cases;
> > the upcoming split-stack cod
Richard Sandiford wrote:
> "Ulrich Weigand" writes:
> > The problem is not DImode LABEL_REFs, but rather VOIDmode LABEL_REFs when
> > matched against a match_operand:DI.
>
> It'd be good to fix this in a more direct way though, rather than
> hack around
nally) as temp register in s390_emit_prologue in certain cases;
the upcoming split-stack code will also need to use r1 in some cases.
r2 through r4 should be fine. [ Not sure if there will be many (any?) cases
where one of those is unused but r5 isn't, however. ]
Bye,
Ulrich
--
Dr. Ulrich
s not DImode LABEL_REFs, but rather VOIDmode LABEL_REFs when
matched against a match_operand:DI.
Otherwise, this patch is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
see that the sh port uses this:
(define_mode_attr lowpart_be [(QI "3") (HI "2")])
[(set (reg:SI T_REG)
(eq:SI
(subreg:QIHI
(and:SI (match_operand:SI 0 "arith_reg_operand")
(match_operand:SI 1 "arith_reg_oper
atch_operand:P 2 "shift_count_or_setmem_operand" "Y")]
UNSPEC_P_TO_BLK)
(match_operand 4 "const_int_operand" "n"))
(This explains why the pattern would never match.)
The AND should be on the filler byte instead:
(unspec:BL
1 - 100 of 480 matches
Mail list logo
