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
"Paul Edwards" wrote on 03.09.2021 13:35:10:
> > Specifically, if you try to run AMODE64 with Pmode equals
> > SImode, the compiler will not be aware that the hardware
> > uses the high 32 bits of base and index registers, and
> > will not necessarily keep them zero.
> The compiler
"Paul Edwards" wrote on 02.09.2021 22:05:39:
> > Is this about supporting a 4GB address space instead
> > of a 2GB space?
>
> Yes, correct.
OK, that makes things clearer. This implies in particular:
- 4GB address space means you need to run in AMODE64
- AMODE64 means the native address size
"Paul Edwards" wrote on 02.09.2021 17:26:25:
> > Therefore again my question, what is the actual goal
> > you want to achieve? I'm still not sure I understand
> > that ...
> I would like to know what is required to implement
> “-m32” in the S/390 target. I realize that z/Arch
> doesn’t have
"Paul Edwards" wrote on 02.09.2021 16:50:35:
> Could you give me an example of an instruction
> generated by –m31 that is not expected to work
> on an AM64 system?
Well, everything related to address computation, of course.
For example, GCC may use LA on -m31 to implement a
31-bit addition,
Hi Paul,
> I just checked my copy of s390.md and I don’t see
> LA being used for arithmetic.
This would be the "*la_31" and "*la_31_and" patterns.
(Note that the addition is implicit in the use of
the "address_operand" constraint.)
> If your copy of s390.md is using LA for arithmetic
> then
Hi Paul,
"Paul Edwards" wrote on 02.09.2021 10:15:44:
> We got the IPL process in place on ESA/390, and then
> I decided that the next thing to do would be to switch
> to z/Arch so that we could get rid of the AMODE 31
> architectural limit on 32-bit programs.
>
> It all worked fine, and we
do here?
>
> This kind of extension is pretty normal in DWARF, so I think it isn't a
> big deal to emit it. Consumers are ordinarily expected to simply ignore
> things they don't understand.
Given Eric's GCC change above, this is no longer necessary now.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
rence_type, DW_TAG_rvalue_reference_type,
DW_TAG_ptr_to_member_type and possibly others). Also, the
implementation in GDB would need to be changed accordingly.
Any comments or suggestions on what to do here?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
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
Joseph Myers wrote:
> On Tue, 28 Jan 2020, Ulrich Weigand wrote:
>
> > The following patch (not yet fully tested) implements the above changes.
> > Note that this now brings the set of flags set and reset by
> > set_fast_math_flags completely in sync with the
Joseph Myers wrote:
> On Mon, 27 Jan 2020, Ulrich Weigand wrote:
> > I see. I guess that makes me wonder what -fno-fast-math *ever* does
> > (except canceling a -ffast-math earlier on the command line). Looking
> > at the current code, -fno-fast-math (just like -ffast-mat
Joseph Myers wrote:
> On Tue, 21 Jan 2020, Ulrich Weigand wrote:
>
> > It looks like there's multiple cases here. For the two flags
> > -fassociative-math and -freciprocal-math, it seems to have happened just as
> > you describe: they were created (split out of -fu
Joseph Myers wrote:
> On Mon, 20 Jan 2020, Ulrich Weigand wrote:
>
> > This has the effect that e.g. after
> >
> > -ffast-math -fno-finite-math-only
> >
> > the __FAST_MATH__ macro is no longer predefined, but after
> >
> > -ffast-math -fno-a
by -ffast-math?
Bye,
Ulrich
--
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
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
/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
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
er operand, which is written before the instruction is
finished using the input operands. Therefore, this operand may not lie
in a register that is read by the instruction or as part of any memory
address.
Note in particular "... as part of any memory address."
Bye,
Ulrich
--
Dr. Ulr
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
re probably
would have to be extra work in the libraries to enable 31-bit mode.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Szabolcs Nagy wrote:
> On 20/12/16 13:26, Ulrich Weigand wrote:
> > I may have missed the context of the discussion, but just on the
> > specific ISA question here: both Power and z not only have the
> > 16-byte CAS (or load-and-reserve/store-conditional), but they also both
ructions to implement atomic operations on
16-byte data types on those machines.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
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
1 - 100 of 613 matches
Mail list logo
