Context dependent expression simplification
Hello, Before I start to write code to reinvent the wheel, I would like to know if there's something already out there to do context dependent expression simplification. What I need is to simplify an expression at a given point in a BB. For example: bb2: r1 <- 2 if r2 != 0 goto bb3 else bb4 bb3: r3 <- r2 << 1 goto bb4 bb4: ... ... if ... goto bb4 else bb5 Is there any way already implemented to find the value of (and (plus r1 r3) (const_int 1)) at the end of bb4 and simplify it to (const_int 0)? Cheers, Paulo Matos
Re: Context dependent expression simplification
On Tue, Jan 14, 2014 at 01:40:36PM +, Paulo Matos wrote: > Before I start to write code to reinvent the wheel, I would like to know if > there's something already out there to do context dependent expression > simplification. > What I need is to simplify an expression at a given point in a BB. > > For example: > > bb2: >r1 <- 2 >if r2 != 0 goto bb3 else bb4 > bb3: >r3 <- r2 << 1 >goto bb4 > bb4: >... >... >if ... goto bb4 else bb5 > > Is there any way already implemented to find the value of (and (plus r1 r3) > (const_int 1)) at the end of bb4 and simplify it to (const_int 0)? VRP should handle this (of course at the GIMPLE level) performs context dependent optimizations through it's edge assertions. Jakub
RE: Context dependent expression simplification
> -Original Message- > From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: 14 January 2014 13:45 > To: Paulo Matos > Cc: gcc@gcc.gnu.org > Subject: Re: Context dependent expression simplification > > On Tue, Jan 14, 2014 at 01:40:36PM +, Paulo Matos wrote: > > Before I start to write code to reinvent the wheel, I would like to know if > there's something already out there to do context dependent expression > simplification. > > What I need is to simplify an expression at a given point in a BB. > > > > For example: > > > > bb2: > >r1 <- 2 > >if r2 != 0 goto bb3 else bb4 > > bb3: > >r3 <- r2 << 1 > >goto bb4 > > bb4: > >... > >... > >if ... goto bb4 else bb5 > > > > Is there any way already implemented to find the value of (and (plus r1 r3) > (const_int 1)) at the end of bb4 and simplify it to (const_int 0)? > > VRP should handle this (of course at the GIMPLE level) performs context > dependent optimizations through it's edge assertions. I need to do this during loop_doloop to simplify infinite conditons. Might have to implement something to do this at RTL level then. Paulo Matos > > Jakub
Re: [Ping, IRA] Segfault in ira_costs.c:find_costs_and_classes for AVR target
On 01/13/2014 03:54 AM, Senthil Kumar Selvaraj wrote: > Ping ! > > Regards > Senthil > > On Thu, Dec 26, 2013 at 03:11:25PM +0530, Senthil Kumar Selvaraj wrote: >> Hi, >> >> gcc.c-torture/compile/pr34856.c and a couple of other tests segfault >> for the AVR target. Looking at the code, I found that the >> x_ira_register_move_cost array[TImode] is NULL, while the code goes on >> to dereference it (ira_register_move_cost >> [ALLOCNO_MODE (a)][best][aclass] at line 1832). >> >> I looked at the code that populates the array, and found that it does >> explicitly allow the array to have NULL entries for certain modes, >> atleast during initialization. >> >> I'm not really sure how this should be fixed - is NULL valid or is the >> AVR target violating some invariant? >> >> Regards >> Senthil >> >> >> Sorry for the delay with the answer. NULL is not valid. IRA calculates many internal data structures. So some people implemented a lazy approach in such data structure calculation (NULL means that the data were not calculated yet). Probably, one place was missed or added lately without checking that data were calculated. I'll look at this and fix the problem this week. Thanks for pointing this out, Senthil.
Re: [IRA] Segfault in ira_costs.c:find_costs_and_classes for AVR target
On 12/26/2013 04:41 AM, Senthil Kumar Selvaraj wrote: > Hi, > > gcc.c-torture/compile/pr34856.c and a couple of other tests segfault > for the AVR target. Looking at the code, I found that the > x_ira_register_move_cost array[TImode] is NULL, while the code goes on > to dereference it (ira_register_move_cost > [ALLOCNO_MODE (a)][best][aclass] at line 1832). > > I looked at the code that populates the array, and found that it does > explicitly allow the array to have NULL entries for certain modes, > atleast during initialization. > > I'm not really sure how this should be fixed - is NULL valid or is the > AVR target violating some invariant? > The following patch fixes the problem. Committed as rev. 206606. 2014-01-14 Vladimir Makarov * ira-costs.c (find_costs_and_classes): Add missed ira_init_register_move_cost_if_necessary. Index: ira-costs.c === --- ira-costs.c (revision 206579) +++ ira-costs.c (working copy) @@ -1827,6 +1827,7 @@ find_costs_and_classes (FILE *dump_file) int ind = cost_classes_ptr->index[aclass]; ira_assert (ind >= 0); + ira_init_register_move_cost_if_necessary (ALLOCNO_MODE (a)); ira_add_allocno_pref (a, ira_class_hard_regs[best][0], (a_costs[ind] - ALLOCNO_CLASS_COST (a)) / (ira_register_move_cost
Re: PATCH: PR ld/16428: Disallow -shared/-pie, -shared/-static, -pie/-static
On Tue, Jan 14, 2014 at 10:35 AM, Cary Coutant wrote:
>
>> I see no reason why "-static -pie" should not work. "-static" does
>> *not* specify the type of output directly. "-static" chooses input
>> objects. "-pie" affects output. The two options are logically
>> orthogonal. You ought to be able to build a PIE that doesn't use any
>> shared libraries! If it doesn't work, then we have a bug elsewhere.
>
> Well, in gold, -Bstatic -pie is fine -- that asks to build a PIE with
> just archive libraries, but the output is still going to be an ET_DYN.
> In practice, at least in the ELF world, PIE binaries are dynamic even
> if they have no dependencies on shared libraries.
"-static -pie" may work with linker. But it doesn't work with
GCC driver:
*link:
%{!static:--eh-frame-hdr} %{!mandroid|tno-android-ld:%{m32|mx32:;:-m
elf_x86_64}%{m32:-m elf_i386}
%{mx32:-m elf32_x86_64} %{shared:-shared} %{!shared:
%{!static: %{rdynamic:-export-dynamic}
%{m32:-dynamic-linker
%{muclibc:/lib/ld-uClibc.so.0;:%{mbionic:/system/bin/linker;:/lib/ld-linux.so.2}}}
%{m32|mx32:;:-dynamic-linker
%{muclibc:/lib/ld64-uClibc.so.0;:%{mbionic:/system/bin/linker64;:/lib64/ld-linux-x86-64.so.2}}}
%{mx32:-dynamic-linker
%{muclibc:/lib/ldx32-uClibc.so.0;:%{mbionic:/system/bin/linkerx32;:/libx32/ld-linux-x32.so.2
%{static:-static}};:%{m32|mx32:;:-m elf_x86_64}
%{m32:-m elf_i386}%{mx32:-m elf32_x86_64}
%{shared:-shared} %{!shared: %{!static:
%{rdynamic:-export-dynamic} %{m32:-dynamic-linker
%{muclibc:/lib/ld-uClibc.so.0;:%{mbionic:/system/bin/linker;:/lib/ld-linux.so.2}}}
%{m32|mx32:;:-dynamic-linker
%{muclibc:/lib/ld64-uClibc.so.0;:%{mbionic:/system/bin/linker64;:/lib64/ld-linux-x86-64.so.2}}}
%{mx32:-dynamic-linker
%{muclibc:/lib/ldx32-uClibc.so.0;:%{mbionic:/system/bin/linkerx32;:/libx32/ld-linux-x32.so.2
%{static:-static}} %{shared: -Bsymbolic}}
When there is -static, -dynamic-linker won't passed to ld. -static,
-shared, -pie should be mutually exclusive for GCC driver.
> Based on what you've said, I'm inclined to agree with you about Gnu
> ld, though. As long as ld doesn't get into any internal inconsistency
> if given seemingly conflicting options (e.g., if "-static -dynamic"
> always means "-dynamic"), there seems to be little reason to add the
> checking. I guess it's a matter of whether that's more likely to be a
> mistake that needs a diagnostic, or a convenience where LDFLAGS can
> override a setting hardcoded into the Makefile.
I checked in a patch to avoid bfd linker crash.
--
H.J.
Re: PATCH: PR ld/16428: Disallow -shared/-pie, -shared/-static, -pie/-static
On Tue, 14 Jan 2014, H.J. Lu wrote: > When there is -static, -dynamic-linker won't passed to ld. -static, > -shared, -pie should be mutually exclusive for GCC driver. A static PIE shouldn't specify an interpreter; it should handle all dynamic relocation processing itself. Thus, it's correct not to specify -dynamic-linker when building a static PIE. ld.so itself is a static PIE - it specifies no PT_INTERP or DT_NEEDED, and is position-independent. The concept of an arbitrary program meeting those conditions, including a copy of the relevant parts of the dynamic linker to relocate itself, is perfectly meaningful; it just so happens that glibc, and the associated GCC specs, don't support it, but I'm not aware of any fundamental problem with supporting it in ld given appropriate startup code and static libc built as PIC. (I don't know how useful more general static PIE support would be.) (-shared and -pie do seem mutually exclusive, as the first says what's being linked operates as a library and the second says it operates as an executable - although of course the same ET_DYN can operate as both.) -- Joseph S. Myers jos...@codesourcery.com
Re: PATCH: PR ld/16428: Disallow -shared/-pie, -shared/-static, -pie/-static
On Tue, Jan 14, 2014 at 11:37 AM, Joseph S. Myers
wrote:
> On Tue, 14 Jan 2014, H.J. Lu wrote:
>
>> When there is -static, -dynamic-linker won't passed to ld. -static,
>> -shared, -pie should be mutually exclusive for GCC driver.
>
> A static PIE shouldn't specify an interpreter; it should handle all
> dynamic relocation processing itself. Thus, it's correct not to specify
> -dynamic-linker when building a static PIE.
If -dynamic-linker isn't specified, linker will use
the default dynamic linker:
[hjl@gnu-6 pr16428]$ cat x.c
int main() { return 0; }
[hjl@gnu-6 pr16428]$ make
gcc -m32 -B./ -pie -static -fPIE -c -o x.o x.c
gcc -m32 -B./ -pie -static -o x x.o
./x
make: ./x: Command not found
make: *** [all] Error 127
[hjl@gnu-6 pr16428]$ readelf -l x
Elf file type is DYN (Shared object file)
Entry point 0x10d0b
There are 8 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x34 0x0034 0x0034 0x00100 0x00100 R E 0x4
INTERP 0x000134 0x0134 0x0134 0x00013 0x00013 R 0x1
[Requesting program interpreter: /usr/lib/libc.so.1]
LOAD 0x00 0x 0x 0xb6fda 0xb6fda R E 0x1000
LOAD 0x0b7000 0x000b7000 0x000b7000 0x00e40 0x02534 RW 0x1000
DYNAMIC0x0b70b0 0x000b70b0 0x000b70b0 0x000d0 0x000d0 RW 0x4
NOTE 0x000148 0x0148 0x0148 0x00044 0x00044 R 0x4
TLS0x0b7000 0x000b7000 0x000b7000 0x00010 0x00028 R 0x4
GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x10
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym
.dynstr .rel.dyn .rel.plt .init .plt .text __libc_thread_freeres_fn
__libc_freeres_fn .fini .rodata .stapsdt.base __libc_thread_subfreeres
__libc_subfreeres __libc_atexit .eh_frame .gcc_except_table
03 .tdata .init_array .fini_array .jcr .data.rel.ro .dynamic
.got .got.plt .data .bss __libc_freeres_ptrs
04 .dynamic
> ld.so itself is a static PIE - it specifies no PT_INTERP or DT_NEEDED, and
> is position-independent. The concept of an arbitrary program meeting
> those conditions, including a copy of the relevant parts of the dynamic
> linker to relocate itself, is perfectly meaningful; it just so happens
> that glibc, and the associated GCC specs, don't support it, but I'm not
> aware of any fundamental problem with supporting it in ld given
> appropriate startup code and static libc built as PIC. (I don't know how
> useful more general static PIE support would be.)
-static -PIE may make sense to ld, but not to GCC driver,
at least, not on Linux/x86 where the dynamic linker isn't
/usr/lib/libc.so.1
> (-shared and -pie do seem mutually exclusive, as the first says what's
> being linked operates as a library and the second says it operates as an
> executable - although of course the same ET_DYN can operate as both.)
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
--
H.J.
Re: PATCH: PR ld/16428: Disallow -shared/-pie, -shared/-static, -pie/-static
On Tue, 14 Jan 2014, H.J. Lu wrote: > On Tue, Jan 14, 2014 at 11:37 AM, Joseph S. Myers > wrote: > > On Tue, 14 Jan 2014, H.J. Lu wrote: > > > >> When there is -static, -dynamic-linker won't passed to ld. -static, > >> -shared, -pie should be mutually exclusive for GCC driver. > > > > A static PIE shouldn't specify an interpreter; it should handle all > > dynamic relocation processing itself. Thus, it's correct not to specify > > -dynamic-linker when building a static PIE. > > If -dynamic-linker isn't specified, linker will use > the default dynamic linker: I'd say that's a bug in ld - that it shouldn't specify an interpreter at all (that the startup code / libc for static PIEs needs to include all the relevant parts of the dynamic linker to make the binary relocate itself). -- Joseph S. Myers jos...@codesourcery.com
Re: PATCH: PR ld/16428: Disallow -shared/-pie, -shared/-static, -pie/-static
On Tue, Jan 14, 2014 at 1:45 PM, Joseph S. Myers wrote: > On Tue, 14 Jan 2014, H.J. Lu wrote: > >> On Tue, Jan 14, 2014 at 11:37 AM, Joseph S. Myers >> wrote: >> > On Tue, 14 Jan 2014, H.J. Lu wrote: >> > >> >> When there is -static, -dynamic-linker won't passed to ld. -static, >> >> -shared, -pie should be mutually exclusive for GCC driver. >> > >> > A static PIE shouldn't specify an interpreter; it should handle all >> > dynamic relocation processing itself. Thus, it's correct not to specify >> > -dynamic-linker when building a static PIE. >> >> If -dynamic-linker isn't specified, linker will use >> the default dynamic linker: > > I'd say that's a bug in ld - that it shouldn't specify an interpreter at > all (that the startup code / libc for static PIEs needs to include all the > relevant parts of the dynamic linker to make the binary relocate itself). > The -static part of "-static -pie" passed to linker tells linker searches libfoo.a, not libfoo.so for -lfoo. You can add -Bdynamic to change it for latter inputs. It has nothing to do if interpreter is used or not. -- H.J.
