Abe wrote:
Hi, pleased to meet you :)
As some of you already know, at SARC we are working on a new "if converter" to
help convert
simple "if"-based blocks of code that appear inside loops into an
autovectorizer-friendly form
that closely resembles the C ternary operator ["c ? x : y"]. G
Abe wrote:
In other words, the problem about which I was concerned is not going to be triggered by
e.g. "if (c) x = ..."
which lacks an attached "else x = ..." in a multithreaded program without
enough locking just because 'x' is global/static.
The only remaining case to consider is if some
Abe wrote:
[snip]
Predication of instructions can help to remove the burden of the conditional
branch, but is not available on all relevant architectures.
In some architectures that are typically implemented in modern high-speed
processors -- i.e. with high core frequency, caches, speculative e
Abe wrote:
of course this says nothing about whether there is *some* other ISA that gets
regressed!
After finishing fixing the known regressions, I intend/plan to reg-test for
AArch64;
after that, I think I`m going to need some community help to reg-test for other
ISAs.
OK, I'm confused.
Abe wrote:
Ideally, I/we fix the above problem -- and the rest of the regressions in the
new if converter --
Ok, what are these regressions? You say you've tested on x86_64 and only
ifcvt-18.c fails (hence your xfail), so how does one find them?
In particular, I remember that "result = co
Hi!
All compilers can replace multiplication operation by bit shifts and LEA x86
instruction
(if current target arch is x86).
Can I ask, where in GCC this happens? I can't find it in source code.
See gcc/expmed.c, search for "choose_mult_variant".
HTH
Alan
Abe wrote:
Dear all,
Overall, I think the WIP new if converter is holding up
relatively well, but there is obviously opportunity to do better,
at least if the numbers mean what they look like they mean,
i.e. the old converter`s code was fully OK and so is the new one`s.
By "fully OK" I mean e.g.
I've been erratically seeing my Ada builds (bootstrap or even with
--disable-bootstrap) on an arm-none-linux-gnueabihf system, with errors like this:
g++ -fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-str
On 07/10/15 18:33, Eric Botcazou wrote:
So it looks like there are two problems here:
(1) xsinfo not terminating;
(2) a missing dependency, that the g++ steps should depend upon the step
producing sinfo.h (i.e. the mv that comes after problem (1))
I'm going to look at (1), but I'm hoping someone
On 12/10/15 10:58, Eric Botcazou wrote:
Yes, that fixes the dependency problem; the build waits for the xsinfo to
terminate. This at least makes it easy to Ctrl-C and try again. Are we aware
of any reason why *not* to make that change?
You may have noticed that I had made it before you posted t
Hi,
I'm having fun with arrays in Ada ;) and wondering if anyone can tell me what's
right here.
Ada ACATS c64106a contains code with an array type whose indices run from -1 to
1. (That is, three elements.)
In GCC this gets represented as an ARRAY_TYPE, whose TYPE_DOMAIN is a 32-bit
signed
Can anyone give me any pointers on how to use the -mpaired option ("PowerPC
750CL paired-single instructions") ? I'm trying to get it to use the
reduc_s{min,max,plus}_v2sf patterns in gcc/config/rs6000/paired.md, so far I
haven't managed to find a configuration that supports loading a vector of
On Tues, Oct 27, 2015 at 2:39 PM, Richard Biener
wrote:
On Mon, Oct 26, 2015 at 6:59 AM, sameera wrote:
Richard, we have defined the input language for convenience in prototype
implementation. However, we will be using GIMPLE as our IR. As per grammar
of our tree, p-tree denote the permute o
I'm looking at git commit ea1ac559 / svn r76965, January 2014 (archive:
https://gcc.gnu.org/ml/gcc-patches/2004-01/msg03406.html), which prevents
(ashiftrt (xor A C1) C2)
from being commuted to
(xor (ashiftrt A C2) (ashiftrt C1 C2))
and wondering if anyone can explain to me what's wrong with t
Thanks for the quick response - the possibility of different modes seems
plausible, as I'm not sure what would happen in that case. (Although I'm not
entirely sure how that case would occur - something that may have changed since
the original.) I haven't had much luck in getting a working toolchai
Hi,
I've been experimenting with some small testcases with the aim of getting the
vectorizer to work on more loops. I started by compiling at -O3 the following
testcase:
#define N 32
int a[N];
int b[N];
int foo ()
{
for (int i = 0; i < N ; i++)
{
int m = (a[i] & i) ? 5 : 4;
Ajit Kumar Agarwal wrote:
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Richard
Biener
Sent: Tuesday, April 28, 2015 4:12 PM
To: Jeff Law
Cc: Alan Lawrence; gcc@gcc.gnu.org
Subject: Re: dom1 prevents vectorization via partial loop peeling
Richard Biener wrote:
Well. In this case we hit
/* If one of the loop header's edge is an exit edge then do not
apply if-conversion. */
FOR_EACH_EDGE (e, ei, loop->header->succs)
if (loop_exit_edge_p (loop, e))
return false;
which is simply because even after if-conversion
18 matches
Mail list logo
