On December 9, 2017 11:08:18 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>compute_access_stride does:
> tree ref = DR_REF (dr);
> tree scev_base = build_fold_addr_expr (ref);
>but that really isn't valid for bitfield drs, where we can't take
>addresses
>of the bitfield.
>As I understood this func
This patch makes the AArch64 vec_perm_const code use the new
vec_perm_indices routines, instead of checking each element individually.
This means that they extend naturally to variable-length vectors.
Also, aarch64_evpc_dup was the only function that generated rtl when
testing_p is true, and that
The previous patches mean that there's no reason that constant
VEC_PERM_EXPRs need to have the same shape as the data inputs.
This patch makes the autovectoriser use ssizetype elements instead,
so that indices don't get truncated for large or variable-length vectors.
2017-12-09 Richard Sandiford
This patch makes shift_amt_for_vec_perm_mask use series_p to check
for the simple case of a natural linear series before falling back
to testing each element individually. The series_p test works with
variable-length vectors but testing every individual element doesn't.
2017-12-09 Richard Sandi
This patch reworks the VEC_PERM_EXPR folding so that more of it works
for variable-length vectors. E.g. it means that we can now recognise
variable-length permutes that reduce to a single vector, or cases in
which a variable-length permute only needs one input. There should be
no functional chang
This patch makes users of vec_perm_builders use the compressed encoding
where possible. This means that they work with variable-length vectors.
2017-12-09 Richard Sandiford
gcc/
* optabs.c (expand_vec_perm_var): Use an explicit encoding for
the broadcast of the low byte.
This patch adds a function for creating a VECTOR_CST from a
vec_perm_indices, operating directly on the encoding.
2017-12-09 Richard Sandiford
gcc/
* vec-perm-indices.h (vec_perm_indices_to_tree): Declare.
* vec-perm-indices.c (vec_perm_indices_to_tree): New function.
This patch changes vec_perm_indices from a plain vec<> to a class
that stores a canonicalised permutation, using the same encoding
as for VECTOR_CSTs. This means that vec_perm_indices now carries
information about the number of vectors being permuted (currently
always 1 or 2) and the number of ele
The patch to remove the vec_perm_const optab checked whether replacing
a constant permute with a variable permute is safe, or whether it might
truncate the indices. This patch adds a corresponding check for whether
variable permutes can be lowered to QImode-based permutes.
2017-12-09 Richard Sa
One of the changes needed for variable-length VEC_PERM_EXPRs -- and for
long fixed-length VEC_PERM_EXPRs -- is the ability to use constant
selectors that wouldn't fit in the vectors being permuted. E.g. a
permute on two V256QIs can't be done using a V256QI selector.
At the moment constant permute
This patch splits the variable handling out of expand_vec_perm into
a subroutine, so that the next patch can use a different interface
for expanding constant permutes. expand_vec_perm now does all the
CONST_VECTOR handling directly and defers to expand_vec_perm_var
for other rtx codes. Handling C
This patch splits can_vec_perm_p into two functions: can_vec_perm_var_p
for testing permute operations with variable selection vectors, and
can_vec_perm_const_p for testing permute operations with specific
constant selection vectors. This means that we can pass the constant
selection vector by ref
This patch makes functions take vec_perm_indices by reference rather
than value, since a later patch will turn vec_perm_indices into a class
that would be more expensive to copy.
2017-12-06 Richard Sandiford
gcc/
* fold-const.c (fold_vec_perm): Take a const vec_perm_indices &
The vec_perm code falls back to doing byte-level permutes if
element-level permutes aren't supported. There were two copies
of the code to calculate the mode, and later patches add another,
so this patch splits it out into a helper function.
2017-12-09 Richard Sandiford
gcc/
* optabs
This series is a replacement for:
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00747.html
based on the feedback that using VEC_PERM_EXPR would be better.
The changes are:
(1) Remove the restriction that the selector elements have to have the
same width as the data elements, but only for cons
Hi!
compute_access_stride does:
tree ref = DR_REF (dr);
tree scev_base = build_fold_addr_expr (ref);
but that really isn't valid for bitfield drs, where we can't take addresses
of the bitfield.
As I understood this function only wants to compute strides, so constant bit
offsets shouldn't make
On Wed, 22 Nov 2017, Jeff Law wrote:
>>> * gimple-ssa-evrp-analyze.c: New file pulled from gimple-ssa-evrp.c.
>>
>> With the move to C++, wasn't there a policy to name new files *.cc
>> instead of *.c?
> I'm happy to use .cc if that's where we want to go. It's trivial
> and we're not losing any
On Fri, Dec 08, 2017 at 05:13:28PM -0800, Steve Kargl wrote:
> The attached patch enforces F2008:C631, which of course is
>
> /* F2008:C631 (R626) A type-param-value in a type-spec shall be an
>asterisk if and only if each allocate-object is a dummy argument
>for which the corresponding ty
On Sat, Dec 09, 2017 at 06:41:14PM +0100, Gerald Pfeifer wrote:
> Some users on FreeBSD noticed a problem when trying to use GCC to
> build things in a standalone environment that manifests itself as
>
> /usr/local/lib/gcc/x86_64-unknown-freebsd11.0/6.3.0/include/xmmintrin.h:34
> from
> /usr/loca
Some users on FreeBSD noticed a problem when trying to use GCC to
build things in a standalone environment that manifests itself as
/usr/local/lib/gcc/x86_64-unknown-freebsd11.0/6.3.0/include/xmmintrin.h:34 from
/usr/local/lib/gcc/x86_64-unknown-freebsd11.0/6.3.0/include/immintrin.h:29 from
/works
Hi Steve,
I can generate such a test but it will have to wait until I have
finished doing all my Christmas cards :-)
As for the dead code, that is not what is intended and might explain
some difficulties that I have had with the code in decl.c.
Cheers
Paul
On 9 December 2017 at 16:21, Steve K
On Sat, Dec 09, 2017 at 09:09:14AM +, Paul Richard Thomas wrote:
>
> This is good for trunk with one proviso:
>
> This should mutate from:
> - /* TODO understand why this error does not appear but, instead,
> - the derived type is caught as a variable in primary.c. */
> - if (gfc_spec_
Hi Julia,
On Mon, 4 Dec 2017, Koval, Julia wrote:
> Do you think it is ok to copypaste it from GCC-6?
you mean copy, past, and adjust? Yes, that should work.
> GCC now supports the Intel CPU, named Cannonlake through
> -march=cannonlake. The switch enables the following ISA extensions:
> AVX5
Thanks for the review. Third revision of the patch attached.
Martin Sebor writes:
> >>>+/* { dg-options "-ffile-prefix-map==FILE-PREFIX" } */
> >>
> >>What's up with this "=="? (as opposed to "=").
> >
> >Since I cannot predict the actual path, I am remapping empty prefix
> >to FILE-PREFIX which
That requires updates to gcc.dg/pr53037-4.c and g++.dg/pr53037-4.C.
FAIL: gcc.dg/pr53037-4.c (test for excess errors)
Excess errors:
/usr/local/gcc/gcc-20171208/gcc/testsuite/gcc.dg/pr53037-4.c:9:1: er
On December 9, 2017 10:50:12 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>When POINTER_PLUS_EXPR is vectorized, we vectorize it as a vector
>PLUS_EXPR.
>This (usually? Not sure about targets where sizetype has different
>precision from POINTER_SIZE; maybe those just don't have vector types)
>works
Hi!
When POINTER_PLUS_EXPR is vectorized, we vectorize it as a vector PLUS_EXPR.
This (usually? Not sure about targets where sizetype has different
precision from POINTER_SIZE; maybe those just don't have vector types) works
because we vectorize pointer variables as vectors of unsigned pointer si
Hi Steve,
This is good for trunk with one proviso:
This should mutate from:
- /* TODO understand why this error does not appear but, instead,
- the derived type is caught as a variable in primary.c. */
- if (gfc_spec_list_type (type_param_spec_list, NULL) != SPEC_EXPLICIT)
{
- gf
Hi Steve,
The attached patch enforces F2008:C631, which of course is
/* F2008:C631 (R626) A type-param-value in a type-spec shall be an
asterisk if and only if each allocate-object is a dummy argument
for which the corresponding type parameter is assumed. */
Regression tested on x86_6
29 matches
Mail list logo
