On x86-64, in PIE mode, accesses to external data don't use the conservative
GOT-relative address, but rather use pcrel. A copy relocation will be created
if the external data is defined in a DSO.
// a.o
// (x) GCC<5, movq a@GOTPCREL(%rip), %rax; movl (%rax), %eax
// (y) GCC>=5 (since commit 13
Snapshot gcc-8-20190524 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190524/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8
On 5/24/19 5:36 AM, Richard Biener wrote:
On Fri, May 24, 2019 at 12:27 AM Eric Botcazou wrote:
While I agree that symbolic ranges are a complication and that most
cases it currently handles are not "value-range" things I do not agree
with the idea that we can simply remove handling them and de
On 5/23/19 9:29 AM, Richard Biener wrote:
On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod wrote:
All times are with a release configured compiler. Out of the 242 files,
pretty much across the board in all 4 sets of figures, RVRP was faster
in about 90% of the cases, and slower in the other 10%,
On 5/23/19 10:07 AM, Richard Biener wrote:
On Thu, May 23, 2019 at 3:30 AM Andrew MacLeod wrote:
This aspect of all calculations being driven from the opcode and
combined generically without special casing at a higher level is both
very powerful and less prone to produce errors. Our initial e
On 5/23/19 9:10 AM, Richard Biener wrote:
On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod wrote:
This aspect of symbolics would be handled by a relational/equivalence
processing engine that would be follow on work. Using the same basic
model as ranges, each tree code is taught to understand th
On 5/23/19 8:55 AM, Richard Biener wrote:
On Thu, May 23, 2019 at 3:28 AM Andrew MacLeod wrote:
2 * GORI
The second component is the “Generates Outgoing Range Info” engine.
This is a basic-block oriented component which determines what ssa-names
have ranges created on outgoing edg
On Fri, May 24, 2019 at 12:27 AM Eric Botcazou wrote:
>
> > While I agree that symbolic ranges are a complication and that most
> > cases it currently handles are not "value-range" things I do not agree
> > with the idea that we can simply remove handling them and deal
> > with the fallout in some
> -Original Message-
> From: gcc-ow...@gcc.gnu.org On Behalf Of a b
> Sent: 23 May 2019 21:04
> To: gcc gcc
> Subject: What are the optimizations that contribute to ~70% improvement on
> SPEC06 hmmer benchmark?
>
> Recently I happen to notice that there is more than 70% performance
> imp
On 5/24/19 12:27 AM, Eric Botcazou wrote:
There are a couple of testcases in the testsuite that, I believe, require a
minimal form of support for symbolic ranges: gcc.dg/tree-ssa/vrp94.c and
gnat.dg/opt40.adb. They deal with the following pattern in C:
if (x >= y)
return 1;
z = y -
10 matches
Mail list logo
