Hi,
I think using a different arc64 port is better as the new ARCv3 comes
with some new innovations which are not in the "classical" arc port.
Moreover, the classical arc is implementing arcv1, arcv2 and all kinds
of variations in between. Adding a new 64bit architecture will just
complicate the e
Hi Julian,
I hope you have Ulrich's document about TLS, if not please google it:
"ELF Handling for Thread-Local Storage - Ulrich Drepper"
In ARC, I used unspec constructions to emit TLS addresses. If you
wanna simplify it, in the legitimzie_tls_address you can only
implement the most general case
Hi Julian,
You can check how we did it for ARC. In a nutshell, you need to define
HAVS_AS_TLS macro, you need to legitimize the new TLS address and
calls. Please have a look in arc.cc and search for TLS, also use git
blame to see the original patches. Of course, there are different ways
to impleme
+ gcc mailing list
-- Forwarded message -
From: Claudiu Zissulescu Ianculescu
Date: Tue, Dec 20, 2022 at 2:31 PM
Subject: Re: Possible regression in DF analysis
To: Jeff Law
Hi Jeff,
> Or is that the core of the problem -- that life analysis is inaccurate
> or unavailable?
>
T
Hi Richard,
Sorry for my misunderstanding. I am calling the df_analyze() instead
of df_analyze1() at the end. Shouldn't df_analyze take care and
compute the correct postorder (df-core.cc:1273) ?
Thank you,
Claudiu
On Wed, Dec 14, 2022 at 1:06 PM Richard Biener
wrote:
>
> On Wed, Dec 14, 2022 a
I have update the fix to this one:
diff --git a/gcc/df-core.cc b/gcc/df-core.cc
index a901b84878f..cc6383990a1 100644
--- a/gcc/df-core.cc
+++ b/gcc/df-core.cc
@@ -1437,7 +1437,16 @@ df_analyze_loop (class loop *loop)
df_set_blocks (blocks);
BITMAP_FREE (blocks);
- df_analyze_1 ();
+ /* I
>
> Maybe you want to iterate over the loops exit edges and include their
> destination block instead?
>
This is better approach, let me try it and I will be back to you.
Thanks,
Claudiu
UPDATE:
The df_analyze_loop is calling the df_set_blocks. Thus, the analysis
behaves as if the function only contains those blocks and any edges
that occur directly between the blocks in the set (see df-core.cc).
This said, the loop-doloop behaves faulty at loop-doloop.cc:772 as the
df_get_lives_ou
It looks like that. The df_analyze_loop is only looking at the loop
BBs, and it is not clear for me if df_analyze_loop is required to have
all the df_live_outs correctly computed or not. Do you know if it is
true?
If the df_analyze_loop is not supposed to compute all the df_live_outs
correctly, th
Hi Eric,
The problem shows in loop-doloop.c when I introduce a loop end pattern
that replaces the first jump instruction (JUMP_INSN 15) with a pattern
that clobbers CC reg. However, the DF doesn't look like it works as
the doloop step cannot find the CC reg alive. Please see
loop-doloop.c:766. Henc
Hi,
I've stumbled over a potential issue related to Dataflow analysis,
and maybe you can help me with it. It can be reproduced for AARCH64
but other architectures are affected as well.
I have the next snip before CSE1 pass:
(insn 14 11 15 3 (set (reg:CC 66 cc)
(compare:CC (reg/v:SI 98 [
11 matches
Mail list logo
