https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
Richard Biener changed:
What|Removed |Added
Known to work||10.5.0, 13.2.1, 14.1.0
Resoluti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #12 from Marc Glisse ---
(In reply to Richard Biener from comment #11)
> I guess you meant (notice the bogus memset size above):
True. And while it shouldn't make a difference in checking if the stores to c
are dead, it could (but do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #11 from Richard Biener ---
(In reply to Marc Glisse from comment #5)
> Another example:
>
> #include
> void f(){
> const int n=1<<14;
> double a[n];
> double b[n];
> double c[n];
> __builtin_memset(a,0,n);
> __builtin_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #10 from Richard Biener ---
Created attachment 44146
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44146&action=edit
testresults
Related I checked
Index: gcc/passes.def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #9 from Richard Biener ---
So the following incomplete patch solves the value-numbering issue in FRE2.
diff --git a/gcc/tree-dfa.c b/gcc/tree-dfa.c
index a121b880bb0..745d60cbda5 100644
--- a/gcc/tree-dfa.c
+++ b/gcc/tree-dfa.c
@@ -5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #8 from Richard Biener ---
comment#5 runs into the fact that we cannot reliably compute kills for
loop-variant stores and thus we give up completely:
if (gimple_code (temp) == GIMPLE_PHI)
{
/* If we visit this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #7 from Marc Glisse ---
This PR is messy. To sum up, comment #0 was recently fixed, comment #5 is not
(not noticing that the writes in the loop are dead), and comment #6 asks for
increasing the alignment of VLAs the same way we someti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #6 from Marc Glisse ---
In addition to the issues already described, it seems that we generate better
code if I replace the VLAs with calls to alloca. Indeed, we assume that alloca
returns 16-aligned memory, while with __builtin_alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #5 from Marc Glisse ---
Another example:
#include
void f(){
const int n=1<<14;
double a[n];
double b[n];
double c[n];
__builtin_memset(a,0,n);
__builtin_memset(b,0,n);
__builtin_memset(c,0,n);
for(int i=0;i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #4 from Marc Glisse ---
(In reply to Richard Biener from comment #3)
> Btw, what was the original testcase?
Sorry, I don't remember. Probably something involving std::vector or
std::string. Since llvm optimizes it just fine, I hadn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #3 from Richard Biener ---
Btw, what was the original testcase?
It's all a little bit complicated and not really fit for the current simple
handling of PHIs. Because with a conditional store we have to continue
looking for uses on t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #2 from Marc Glisse ---
(In reply to Richard Biener from comment #1)
> Hm? The PHI does post-dominate the memset. I think you run into another
> check, namely we visited the call already (temp != NULL).
Oups... The original testcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
13 matches
Mail list logo
