> OK. Just checking. Thanks for the code cleanup.
Thanks for the review. Committed as rev. 227208.
FX
On Wed, Aug 26, 2015 at 3:50 AM, Jeff Law wrote:
> On 08/25/2015 05:06 AM, Alan Lawrence wrote:
>>
>> When SRA completely scalarizes an array, this patch changes the
>> generated accesses from e.g.
>>
>> MEM[(int[8] *)&a + 4B] = 1;
>>
>> to
>>
>> a[1] = 1;
>>
>> This overcomes a limitation in dom2
On Tue, Aug 25, 2015 at 07:09:48PM -0500, Segher Boessenkool wrote:
> On Wed, Aug 26, 2015 at 08:40:49AM +0930, Alan Modra wrote:
> > On Tue, Aug 25, 2015 at 10:08:54AM -0700, Segher Boessenkool wrote:
> > > -(define_insn_and_split "*and3_imm_dot_shifted"
> > > - [(set (match_operand:CC 3 "cc_reg_
On Wed, Aug 26, 2015 at 08:40:49AM +0930, Alan Modra wrote:
> On Tue, Aug 25, 2015 at 10:08:54AM -0700, Segher Boessenkool wrote:
> > -(define_insn_and_split "*and3_imm_dot_shifted"
> > - [(set (match_operand:CC 3 "cc_reg_operand" "=x,?y")
> > +(define_insn "*and3_imm_dot_shifted"
> > + [(set (ma
> From: Ulrich Weigand
> Date: Tue, 25 Aug 2015 19:45:06 +0200
> Hans-Peter Nilsson wrote:
> However, neither works for the SPU, because in both cases libtool
> will only do the test whether the target supports the -fPIC option.
> It will not test whether the target supports dynamic libraries.
>
On Wed, Aug 19, 2015 at 07:41:24AM -0500, Segher Boessenkool wrote:
> On Fri, Aug 14, 2015 at 11:46:03AM -0400, Michael Meissner wrote:
> > +;; Like int_reg_operand, but don't return true for pseudo registers
> > +(define_predicate "int_reg_operand_not_pseudo"
> > + (match_operand 0 "register_oper
On Tue, Aug 25, 2015 at 10:08:54AM -0700, Segher Boessenkool wrote:
> -(define_insn_and_split "*and3_imm_dot_shifted"
> - [(set (match_operand:CC 3 "cc_reg_operand" "=x,?y")
> +(define_insn "*and3_imm_dot_shifted"
> + [(set (match_operand:CC 3 "cc_reg_operand" "=x")
Is this really the best solut
The Go frontend erroneously permitted unary ^ on boolean values. This
patch by Chris Manghane fixes the problem, fixing
https://golang.org/issue/11529 . Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
=
On Tue, Aug 18, 2015 at 1:36 PM, Lynn A. Boger
wrote:
>
> libgo/
> PR target/66870
> configure.ac: When gccgo for building libgo uses the gold version
> containing split stack support on ppc64, ppc64le, define
> LINKER_SUPPORTS_SPLIT_STACK.
> configure: Re
Hi,
On Tue, Aug 25, 2015 at 12:06:15PM +0100, Alan Lawrence wrote:
> When SRA completely scalarizes an array, this patch changes the
> generated accesses from e.g.
>
>MEM[(int[8] *)&a + 4B] = 1;
>
> to
>
>a[1] = 1;
>
> This overcomes a limitation in dom2, that accesses to equivalent
>
On Tue, Aug 25, 2015 at 11:58:21PM +0200, Gerald Pfeifer wrote:
> Hi Michael,
>
> On Tue, 25 Aug 2015, Michael Meissner wrote:
> > + A new configuration option
> > ---with-advance-toolchain=at
> > + was added for PowerPC 64-bit Linux systems to use the header files,
> > library
>
> shou
Ended up using the same approach as libatomic,
moving the checking logic into libgupc/configure.tgt.
+# Disable libgupc on unsupported systems.
+if test -d ${srcdir}/libgupc; then
+if test x$enable_libgupc = x; then
+ AC_MSG_CHECKING([for libgupc support])
+ if (srcdir=${srcdir}/l
Hi Michael,
On Tue, 25 Aug 2015, Michael Meissner wrote:
> + A new configuration option
> ---with-advance-toolchain=at
> + was added for PowerPC 64-bit Linux systems to use the header files,
> library
should this be GNU/Linux in the above (per guidance from the FSF)?
> + files, and
On Tue, 25 Aug 2015, H.J. Lu wrote:
>> +Added --enable-default-pie configure option to
>> + generate PIE by default.
>> +
> PING.
How about something more like "The ... configure option enables
generation of PIE by default"? That feels more consistent with
the rest of the page.
Okay
On 08/25/2015 03:42 PM, Martin Jambor wrote:
Hi,
On Tue, Aug 25, 2015 at 12:06:14PM +0100, Alan Lawrence wrote:
This changes the completely_scalarize_record path to also work on arrays (thus
allowing records containing arrays, etc.). This just required extending the
existing type_consists_of_re
Hi,
On Tue, Aug 25, 2015 at 12:06:14PM +0100, Alan Lawrence wrote:
> This changes the completely_scalarize_record path to also work on arrays (thus
> allowing records containing arrays, etc.). This just required extending the
> existing type_consists_of_records_p and completely_scalarize_record me
On 08/21/2015 04:49 AM, Ilya Enkovich wrote:
I want a work with bitmasks to be expressed in a natural way using
regular integer operations. Currently all masks manipulations are
emulated via vector statements (mostly using a bunch of vec_cond). For
complex predicates it may be nontrivial to tran
Hi,
On Tue, Aug 25, 2015 at 12:06:13PM +0100, Alan Lawrence wrote:
> This is a small refactoring/renaming patch, it just moves the call to
> "completely_scalarize_record" out from completely_scalarize_var, and renames
> the latter to create_total_scalarization_access.
>
> This is because the next
On 08/21/2015 06:17 AM, Ilya Enkovich wrote:
Hmm, I don't see how vector masks are more difficult to operate with.
There are just no instructions for that but you have to pretend you
have to get code vectorized.
Also according to vector ABI integer mask should be used for mask
operand in c
I've committed as obvious this patch to fix a build failure this
introduced for targets not defining EXTRA_SPECS, in which case extra_specs
is not declared. (nvptx-none was the target for which I came across such
a failure.)
2015-08-25 Joseph Myers
* gcc.c (driver::finalize): Only
This patch by Chris Manghane fixes the Go frontend to accept numeric
literals with leading zeroes, even if they don't turn out to be octal.
This fixes https://golang.org/issue/11532 and
https://golang.org/issue/11533 . Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to ma
On 08/21/2015 10:30 AM, Ilya Enkovich wrote:
If we're checking an optab to drive an optimization, then we're probably on
the wrong track.
That's totally similar to VEC_COND_EXPR which we generate comparison into.
It is. The vectorizer is riddled with this stuff. Sigh. So I won't
consider th
Mikhail Maltsev writes:
> Hi, all.
> I'm pinging this patch:
> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00030.html
A week and no reply, so FWIW: I really hope this goes in. malloc always
shows up high in my profiles too.
Just a couple of very minor things to show that I read the patch :-)
This patch by Chris Manghane fixes the Go frontend to permit string
slice expressions when the start of the slice is the length of the
setring. This were previously erroneously forbidden when using a
constant index. This fixes https://golang.org/issue/11522 .
Bootstrapped and ran Go testsuite on
On Tue, 2015-08-25 at 13:48 +, Joseph Myers wrote:
> On Thu, 6 Aug 2015, David Malcolm wrote:
>
> > gcc/ChangeLog:
> > * gcc-main.c (main): Add params to driver ctor.
> > * gcc.c (class env_manager): New.
> > (env): New global.
> > (env_manager::init): New.
> > (env_manager
On 08/25/2015 02:14 AM, Christophe Lyon wrote:
Hi,
Some subsets of the tests override ALWAYS_CXXFLAGS or
TEST_ALWAYS_FLAGS and perform effective_target support tests using
these modified flags.
In case these flags conflict with the effective_target tests, it means
that subsequent tests will be
On 08/25/2015 09:44 AM, Marek Polacek wrote:
Here we are ICEing on an invalid code: symtab_node::get asserts that it's
dealing with a function or a static or external variable, but an invalid
decl is rejected too late. So don't try to mark_weak an invalid decl and
also don't duplicate the "decla
On 08/25/2015 05:06 AM, Alan Lawrence wrote:
This makes SRA replace loads of records/arrays from constant pool entries,
with elementwise assignments of the constant values, hence, overcoming the
fundamental problem in PR/63679.
As a first pass, the approach I took was to look for constant-pool l
I've committed this to avoid tripping over another ptx assembler problem.
memcpy is used for block move, and the FUNCTION_DECL for that is created
uniquely in expr.c. It's not linked up to any other decl for memcpy.
PTX requires declarations forexternal symbols, so we emit one for the blkmove
On 08/25/2015 05:06 AM, Alan Lawrence wrote:
I used this as a means of better-testing the previous changes, as it exercises
the constant replacement code a whole lot more. Indeed, quite a few tests are
now optimized away to nothing on AArch64...
Always pulling in constants, is almost certainly n
On 08/25/2015 05:06 AM, Alan Lawrence wrote:
When SRA completely scalarizes an array, this patch changes the
generated accesses from e.g.
MEM[(int[8] *)&a + 4B] = 1;
to
a[1] = 1;
This overcomes a limitation in dom2, that accesses to equivalent
chunks of e.g. MEM[(int[8] *)&a] are not hashable
This patch by Chris Manghane fixes the Go frontend to not crash on
erroneous array types. This fixes https://golang.org/issue/11546 .
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
==
On 08/25/15 15:10, Jeff Law wrote:
On 08/25/2015 08:11 AM, Nathan Sidwell wrote:
We could emulate by creating a new stack frame and shoving the target of the
branch into the stack, then executing a return. However, I don't think that's
worth doing ;-)
And wouldn't work for PTX anyway -- all
On 08/25/2015 05:06 AM, Alan Lawrence wrote:
This changes the completely_scalarize_record path to also work on arrays (thus
allowing records containing arrays, etc.). This just required extending the
existing type_consists_of_records_p and completely_scalarize_record methods
to handle things of A
On 08/25/2015 05:06 AM, Alan Lawrence wrote:
This is a small refactoring/renaming patch, it just moves the call to
"completely_scalarize_record" out from completely_scalarize_var, and renames
the latter to create_total_scalarization_access.
This is because the next patch needs to drop the "_reco
Cesar discovered another quirk of PTX. Inspite of PTX documenting that static
variables can be initialized and default to zero, there's a little note that it
doesn't work for .shared variables. Thus we need code to initialize the worker
lock variable used for reductions.
This implements a ne
On 08/25/2015 08:11 AM, Nathan Sidwell wrote:
Ptx is one of those rare (unique?) machines that doesn't have an
indirect branch. optabs is prepared for such a target and emits a
sorry when an indirect branch is needed. However it then goes on to try
and emit such an instruction and ends up I
> -Original Message-
> From: Andrew Bennett [mailto:andrew.benn...@imgtec.com]
> Sent: Tuesday, July 21, 2015 10:15 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Matthew Fortune; Moore, Catherine
> Subject: [PATCH] MIPS: If a test in the MIPS testsuite requires standard
> library support check t
On Tue, Aug 25, 2015 at 07:10:23PM +0200, FX wrote:
> > Certainly, the dead code can go. But,is this changing the library ABI?
> >
> > troutmask:fvwm:kargl[764] nm /mnt/sgk/work/6/lib/libgfortran.a | grep show_
> > T _gfortrani_show_variables
> > t show_boolean
>
Hans-Peter Nilsson wrote:
> > From: Ulrich Weigand
> > Date: Tue, 25 Aug 2015 14:59:05 +0200
>
> > The other GCC run-time libraries rely on libtool to figure out
> > that even though -fPIC works, dynamic libraries are still not
> > supported on the platform, and thus compile everything for
> > st
This is either blatantly wrong or subtly correct, in which case it needs
a comment. My guess is the former.
OK for branch?
commit 330391636113ed9a9067e6eb639755fb0f4723dc
Author: Aldy Hernandez
Date: Tue Aug 25 10:41:28 2015 -0700
* oacc-init.c (goacc_new_thread): Use correct size o
On 08/25/2015 10:35 AM, Aldy Hernandez wrote:
-int gomp_max_task_priority_var = 0;
+static int gomp_max_task_priority_var = 0;
Sorry I snuck that in there. The variable is unused elsewhere, might as
well make it static.
Aldy
I'm obviously not smart enough to understand libgomp's tasking runtime,
and rth and you get 0 for commenting skills ;-).
I had some notes scribbled down while reading the code, and figured
someone else might read this code some day. It's still in dire need of
commenting, but this mildly helps
On Tue, Aug 25, 2015 at 1:09 PM, Segher Boessenkool
wrote:
> "*ior_mask" is a define_insn_and_split, so it shouldn't use
> can_create_pseudo in its instruction condition, because IRA can then
> create such an instruction, and the condition becomes false before
> the insn is split. Use a scratch i
On Tue, Aug 25, 2015 at 1:08 PM, Segher Boessenkool
wrote:
> The "*and3_imm_dot_shifted" pattern is a define_insn_and_split,
> like most "dot" patterns: if its output is not assigned cr0 but some
> other cr reg, it splits to a non-dot insn and a compare.
>
> Unfortunately that non-dot insn will cl
When forking to call a partitioned routine there is no need to propagate local
state from the active thread to the forked threads.
I've committed this patch to implement that optimization.
nathan
2015-08-25 Nathan Sidwell
* config/nvptx/nvptx.c (nvptx_emit_forking): Add is_call argument,
> Certainly, the dead code can go. But,is this changing the library ABI?
>
> troutmask:fvwm:kargl[764] nm /mnt/sgk/work/6/lib/libgfortran.a | grep show_
> T _gfortrani_show_variables
> t show_boolean
> t show_integer
> t show_sep
"*ior_mask" is a define_insn_and_split, so it shouldn't use
can_create_pseudo in its instruction condition, because IRA can then
create such an instruction, and the condition becomes false before
the insn is split. Use a scratch instead.
Bootstrapped and tested on powerpc64-linux; okay for trunk?
The "*and3_imm_dot_shifted" pattern is a define_insn_and_split,
like most "dot" patterns: if its output is not assigned cr0 but some
other cr reg, it splits to a non-dot insn and a compare.
Unfortunately that non-dot insn will clobber cr0 as well. We could
add another clobber (with "=X,x"), but t
TL;DR: See last...
> From: Ulrich Weigand
> Date: Tue, 25 Aug 2015 14:59:05 +0200
> However, the compiler actually does accept -fPIC. If the flag is
> present, we attempt to generate relocatable code, but only to the
> extent the compiler can do that without support for run-time
> relocations.
On Tue, Aug 25, 2015 at 06:17:13PM +0200, FX wrote:
> Turns out I missed some of the dead code. And I now also fixed comments and
> some formatting.
> libgfortran/runtime/environ.c is now much more readable than before.
> The patch is still a no-op, in terms of user functionality.
> OK to commit t
I installed the following patch on wwwdocs to document the
--with-advance-toolchain= option I added in June:
2015-08-25 Michael Meissner
* changes.html (PowerPC options): Document new configure option
--with-advance-toolchain=at.
Index: htdocs/gcc-6/changes.html
==
Preconnected and internal units currently have their sign mode set to
SIGN_SUPPRESS, rather than the logical value of SIGN_UNSPECIFIED. This does not
matter in most cases, since our chosen processor-dependent behavior is to
suppress optional plus signs anyway…
… except when one tries to overrid
I've committed this to markup more test requirements. Most are obvious enough.
nvptx doesn't expose a normal stack, so stack-based tests fail. It also
requires correct typing on function calls, so lying about that results in
assembler errors. Finally, it doesn't accept string constants, requ
Turns out I missed some of the dead code. And I now also fixed comments and
some formatting.
libgfortran/runtime/environ.c is now much more readable than before.
The patch is still a no-op, in terms of user functionality.
OK to commit to trunk?
FX
unusedcode.ChangeLog
Description: Binary data
Here we are ICEing on an invalid code: symtab_node::get asserts that it's
dealing with a function or a static or external variable, but an invalid
decl is rejected too late. So don't try to mark_weak an invalid decl and
also don't duplicate the "declared weak after being used" check -- that is
alr
On Aug 25, 2015, at 1:14 AM, Christophe Lyon wrote:
> Some subsets of the tests override ALWAYS_CXXFLAGS or
> TEST_ALWAYS_FLAGS and perform effective_target support tests using
> these modified flags.
> This patch adds a new function 'clear_effective_target_cache', which
> is called at the end of
On Thu, May 28, 2015 at 6:49 AM, H.J. Lu wrote:
> OK to install?
>
> H.J.
> ---
> Index: gcc-6/changes.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
> retrieving revision 1.10
> diff -u -p -r1.10 changes.html
> -
On Tue, Aug 25, 2015 at 10:14 AM, Pat Haugen
wrote:
> The following patch fixes the vec_shr expander to do a shift instead of a
> rotate. CPU2006 benchmark 482.sphinx3 recently started failing due to this
> issue. Bootstrapped and tested on ppc64/ppc64le with no new regressions. Ok
> for trunk? A
On reviewing in more detail the changes to pass offloading targets
from the driver to libgomp at link time to identify the minimal
self-contained pieces that can go to trunk, I found that the use of
fnmatch to match against target names was completely unnecessary; the
ISO C90 functions strstr and s
This patch, extracted from a larger change on gomp-4_0-branch, expands
a comment documenting struct switchstr in gcc.c.
Committed.
2015-08-25 Thomas Schwinge
Joseph Myers
* gcc.c (struct switchstr): Expand comment.
Index: gcc.c
==
I've committed this test to check 2-dimensional loops inside a routine.
nathan
2015-08-24 Nathan Sidwell
* testsuite/libgomp.oacc-c-c++-common/routine-wv-1.c: New.
Index: testsuite/libgomp.oacc-c-c++-common/routine-wv-1.c
===
-
> 2015-08-25 James Greenhalgh
>
> * configure.ac: Auto-detect newlib function support unless we
> know there are issues when configuring for a host.
> * configure: Regenerate.
Thanks for CC’ing the fortran list.
Given that this is newlib-specific code, even though it’s in li
Hi,
it was brought to my attention that omp declare target functions were
not properly translated to HSA functions. Until the grand shceme with
an IPA pass is complete, this will do. And having a single predicate
to decide what should be an HSA function cannot be bad. Committed to
the hsa branc
On 25 August 2015 at 15:57, Alan Lawrence wrote:
> Sorry - wrong version posted. The hunk for add_options_for_arm_neon_fp16 has
> moved to the previous patch! This version also fixes some whitespace issues.
>
This looks OK to me now, thanks.
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aa
> Richard Henderson wrote:
> On 08/12/2015 08:59 AM, Wilco Dijkstra wrote:
> > I looked at the statistics of AArch64 immediate generation a while ago.
> > The interesting thing is ~95% of calls are queries, and the same query is on
> > average repeated 10 times in a row. So (a) it is not important
Marcus Shawcroft writes:
> On 19 August 2015 at 15:26, Jiong Wang wrote:
>
>> 2015-08-19 Jiong Wang
>>
>> gcc/
>> * config/aarch64/aarch64.opt (mtls-size): New entry.
>> * config/aarch64/aarch64.c (initialize_aarch64_tls_size): New function.
>> (aarch64_override_options_internal): Call
The following patch fixes the vec_shr expander to do a shift instead of
a rotate. CPU2006 benchmark 482.sphinx3 recently started failing due to
this issue. Bootstrapped and tested on ppc64/ppc64le with no new
regressions. Ok for trunk? And ok for 4.9/5 (with equivalent change to
vec_shl expand
On Fri, Aug 21, 2015 at 11:05:47AM +0100, James Greenhalgh wrote:
> On Thu, Aug 20, 2015 at 10:50:47AM +0100, Marcus Shawcroft wrote:
> > On 20 August 2015 at 09:31, James Greenhalgh
> > wrote:
> > >
> > > Hi,
> > >
> > > Steve's patch in 2013 [1] to fix the MIPS newlib/libgfortran build
> > > c
Ptx is one of those rare (unique?) machines that doesn't have an indirect
branch. optabs is prepared for such a target and emits a sorry when an
indirect branch is needed. However it then goes on to try and emit such an
instruction and ends up ICEing.
Fixed thusly, ok? (Or is the right
I've committed this. A thinko regarding what asm_operands wants for an
argument. Fixes a couple of tests.
nathan
2015-08-25 Nathan Sidwell
* config/nvptx/nvptx.c (nvptx_write_function_decl): Reformat.
(nvptx_reorg_subreg): Pass insn pattern to asm_operands.
Index: gcc/config/nvptx/nvptx
Christophe Lyon wrote:
On 28 July 2015 at 13:27, Alan Lawrence wrote:
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/advsimd-intrinsics/advsimd-intrinsics.exp:
set additional flags for neon-fp16 support.
* gcc.target/aarch64/advsimd-intrinsics/vcvt_f16.c: New.
Is that
Sorry - wrong version posted. The hunk for add_options_for_arm_neon_fp16 has
moved to the previous patch! This version also fixes some whitespace issues.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/advsimd-intrinsics/vcvt_f16.c: New.
* lib/target-supports.exp
(check_effe
On Thu, 6 Aug 2015, David Malcolm wrote:
> gcc/ChangeLog:
> * gcc-main.c (main): Add params to driver ctor.
> * gcc.c (class env_manager): New.
> (env): New global.
> (env_manager::init): New.
> (env_manager::get): New.
> (env_manager::xput): New.
> (env_m
On Tue, 25 Aug 2015, Michael Collison wrote:
> The standard names for signed and unsigned vector wide adds are wrong in the
> documentation.
>
> OK for trunk?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
Christophe Lyon wrote:
On 28 July 2015 at 13:26, Alan Lawrence wrote:
This is a respin of
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00488.html, fixing up the
testsuite for float16 vectors. Relative to the previous version, most of the
additions to the tests are now within #if..#endif such t
Jakub,
This patch changes the launch API for openacc parallels. The current scheme
passes the launch dimensions as 3 separate parameters to the GOACC_parallel
function. This is problematic for a couple of reasons:
1) these must be validated in the host compiler
2) they provide no extension
On 28 July 2015 at 13:27, Alan Lawrence wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aarch64/advsimd-intrinsics/advsimd-intrinsics.exp:
> set additional flags for neon-fp16 support.
> * gcc.target/aarch64/advsimd-intrinsics/vcvt_f16.c: New.
Is that the right version
On 28 July 2015 at 13:26, Alan Lawrence wrote:
> This is a respin of
> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00488.html, fixing up the
> testsuite for float16 vectors. Relative to the previous version, most of the
> additions to the tests are now within #if..#endif such that they are only
Ian Lance Taylor wrote:
> Hans-Peter Nilsson writes:
>
> > * configure.ac: Only compile with -fPIC if the target
> > supports it.
> > * configure: Regenerate.
>
> This is OK.
I'm now running into the same problem on SPU, but unfortnately
this patch still doesn't fix the problem.
No
On 25/08/15 10:52, Andrew Pinski wrote:
On Tue, Aug 25, 2015 at 5:50 PM, Andrew Pinski wrote:
On Tue, Aug 25, 2015 at 5:37 PM, Andre Vieira
wrote:
Conditional branches have a maximum range of [-1048576, 1048572]. Any
destination further away can not be reached by these.
To be able to have con
On Tue, Aug 25, 2015 at 5:29 AM, Hurugalawadi, Naveen
wrote:
> Hi,
>
> Please find attached the remaining part of patch.
>
> Tested the patch on AArch64 and X86 without any regressions.
>
> Please review the patch and let me know if any modifications are required.
Ok.
Thanks,
Richard.
> Thanks,
Alan Lawrence wrote:
All AArch64 patches are unchanged from previous version. However, in response to
discussion, the ARM patches are changed (much as I suggested
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02249.html); this version:
* Hides the existing vcvt_f16_f32 and vcvt_f32_f16 int
When SRA completely scalarizes an array, this patch changes the generated
accesses from e.g.
MEM[(int[8] *)&a + 4B] = 1;
to
a[1] = 1;
This overcomes a limitation in dom2, that accesses to equivalent chunks of e.g.
MEM[(int[8] *)&a] are not hashable_expr_equal_p with accesses to e.g.
ME
This is a small refactoring/renaming patch, it just moves the call to
"completely_scalarize_record" out from completely_scalarize_var, and renames
the latter to create_total_scalarization_access.
This is because the next patch needs to drop the "_record" suffix and I felt
it would be confusing to
Hi,
the patch below adds support for a few unary floating point buitlins
that can be implemented with a single HSA instruction. More effort in
the area of builtins is needed, the motivation for this was a a
benchmark that previously failed with a sorry message. Committed to
the hsa branch.
Mart
Hi,
the patch below fixes two minor issues with new function
gen_hsa_unary_operation and gen_hsa_binary_operation. First, they
should add new instructions to use list of pseudoregiters. Second,
the type opcode should really be int. (It was BrigType16_t, probably
BrigOpcode16_t was intended, but
I used this as a means of better-testing the previous changes, as it exercises
the constant replacement code a whole lot more. Indeed, quite a few tests are
now optimized away to nothing on AArch64...
Always pulling in constants, is almost certainly not what we want, but we may
nonetheless want so
This changes the completely_scalarize_record path to also work on arrays (thus
allowing records containing arrays, etc.). This just required extending the
existing type_consists_of_records_p and completely_scalarize_record methods
to handle things of ARRAY_TYPE as well as RECORD_TYPE. Hence, I rena
ssa-dom-cse-2.c fails on a number of platforms because the input array is pushed
out to the constant pool, preventing later stages from folding away the entire
computation. This patch series fixes the failure by extending SRA to pull the
constants back in.
This is my first patch(set) to SRA and as
This makes SRA replace loads of records/arrays from constant pool entries,
with elementwise assignments of the constant values, hence, overcoming the
fundamental problem in PR/63679.
As a first pass, the approach I took was to look for constant-pool loads as
we scanned through other accesses, and
James Greenhalgh wrote:
>>
>> - VAR1 (UNOP, vec_unpacks_hi_, 10, v4sf)
>> + VAR2 (UNOP, vec_unpacks_hi_, 10, v4sf, v8hf)
>
> Should this not use the appropriate "BUILTIN_..." iterator?
Indeed; BUILTIN_VQ_HSF it is.
>>VAR1 (BINOP, float_truncate_hi_, 0, v4sf)
>>VAR1 (BINOP, float_truncat
The following fixes ICEs due to the genmatch generated code for
GENERIC not verifying if builtin_decl_implicit returns non-NULL.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2015-08-25 Richard Biener
PR middle-end/67306
* genmatch.c (expr::gen_trans
On 19 August 2015 at 15:26, Jiong Wang wrote:
> 2015-08-19 Jiong Wang
>
> gcc/
> * config/aarch64/aarch64.opt (mtls-size): New entry.
> * config/aarch64/aarch64.c (initialize_aarch64_tls_size): New function.
> (aarch64_override_options_internal): Call initialize_aarch64_tls_size.
> * d
The standard names for signed and unsigned vector wide adds are wrong in
the documentation.
OK for trunk?
2015-08-25 Michael Collison
PR other/67320
* doc/md.texi: Rename [su]sum_widen to widen_[su]sum to reflect correct
standard names
diff --git a/gcc/doc/md.texi b/gcc/doc/md.
On Tue, Aug 25, 2015 at 5:50 PM, Andrew Pinski wrote:
> On Tue, Aug 25, 2015 at 5:37 PM, Andre Vieira
> wrote:
>> Conditional branches have a maximum range of [-1048576, 1048572]. Any
>> destination further away can not be reached by these.
>> To be able to have conditional branches in very large
On Tue, Aug 25, 2015 at 5:37 PM, Andre Vieira
wrote:
> Conditional branches have a maximum range of [-1048576, 1048572]. Any
> destination further away can not be reached by these.
> To be able to have conditional branches in very large functions, we invert
> the condition and change the destinati
> 2015-08-19 Marcus Shawcroft
> Jiong Wang
> gcc/
> * config/aarch64/aarch64.c (initialize_aarch64_tls_size): Set default
> tls size for tiny, small, large memory model.
> (aarch64_load_symref_appropriately): Support new symbol types.
> (aarch64_expand_mov_immediate): Likew
This patch allow mode iterators inside angle brackets in machine
description files. I
discovered the issue when attempting to use iterators on match_operand's
as follows:
match_operand: 0 "s_register_operand" "=w")
The function 'read_name' is nor properly handling ':' inside angle brackets.
B
> 2015-08-19 Jiong Wang
>
> gcc/
> * config/aarch64/aarch64-protos.h (aarch64_symbol_type): Rename
> SYMBOL_TLSLE to SYMBOL_TLSLE24.
> * config/aarch64/aarch64.c (aarch64_load_symref_appropriately): Likewise
> (aarch64_expand_mov_immediate): Likewise
> (aarch64_print_operand): Likewise
1 - 100 of 105 matches
Mail list logo
