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
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 for rev
is
> 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 handles branches.
ith 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
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)
> > >
t 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
th_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-math-o
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 i
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
&
mp;& 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
isted 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
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 valu
k;
+ 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
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 p
/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/Linux compilers and
uot;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
use 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 Weigand
l *not* 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
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
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 po
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
nce, 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
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
ies 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
ince 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 and to
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
ou 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
> > >
ne 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
e 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
changes 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. Ulrich
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 the proposed change is
ress_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
com>
+s390 port Hartmut Penner <hepen...@us.ibm.com>
s390 port Ulrich Weigand <uweig...@de.ibm.com>
s390 port Andreas Krebbel <andreas.kreb...@de.ibm.com>
score port Chen Liqin <liqin....@gmail.co
.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 toolc
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
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 fine,
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 4.1.2.
B
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
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
"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_subst"
&g
g 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
> > then we
e)
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 reload registers allocated
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 use in the
reload_vsx_from_gpr splitter, and k
quot;
> + [(parallel
> +[(set (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
ing 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. Ulrich Weigand
G
ng sibcalls) on all objects using split stack.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
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 matter
much either.)
Bye,
Ulrich
ttable_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
anges 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. The
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
t; + "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
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
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
d" "")
> + (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
gt;
> (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
"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
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
"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:
> 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_attr &q
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 code wil
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 i
Richard Sandiford wrote:
> "Ulrich Weigand" <uweig...@de.ibm.com> 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
) 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 Weigand
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
h 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_operand")) )
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:BLK [(and:P (match_operand:P 2 &q
1 - 100 of 452 matches
Mail list logo