[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

2018-01-17 Thread thgarnie at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303 --- Comment #5 from Thomas Garnier --- I didn't try the patch yet, that could be a good starting point (still need change in switch optimization and segment registers). What is the consequence of the change in default_binds_local_p_3? Is it suppo

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

2018-01-19 Thread thgarnie at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303 --- Comment #7 from Thomas Garnier --- Created attachment 43189 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43189&action=edit testcase for mcmodel=large Build with: gcc -mcmodel=large -c -fstatic-pie ./test.c -o test Dump relocations on

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

2018-01-19 Thread thgarnie at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303 Thomas Garnier changed: What|Removed |Added Attachment #43189|0 |1 is obsolete|

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

2018-01-19 Thread thgarnie at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303 --- Comment #9 from Thomas Garnier --- I tested the change against a modified version of the proposed Linux x86_64 PIE support. The changes removes all the PLT32 and GOT64 entry but I still get R_X86_64_GOTPC64 & R_X86_64_GOTOFF64 relocations on

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

2018-01-23 Thread thgarnie at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303 --- Comment #11 from Thomas Garnier --- I think for this file using only -mcmodel=large makes more sense. Given the proposed option (-fstatic-pie) is not kernel specific, the TLS is not needed. What do you think about disabling optimization like

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

2018-01-23 Thread thgarnie at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303 --- Comment #13 from Thomas Garnier --- Created attachment 43223 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43223&action=edit testcase for switch folding No switch folding if built with: $CC -O2 -fno-PIE -c -o switch ./switch.c Swit

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

2018-01-23 Thread thgarnie at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303 --- Comment #14 from Thomas Garnier --- Correcting what I said before, it is about re-enabling switch folding (or switch optimization). Basically without PIE (-fno-PIE) with -O2, a switch can be optimized to be: : 0: b8 00

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

2018-01-23 Thread thgarnie at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303 --- Comment #16 from Thomas Garnier --- Yes, I think you can't just default to the non-PIE mode. Clang does it well though: : 0: 83 ff 16cmp$0x16,%edi 3: 77 0f ja 14 5:

[Bug target/84011] New: Optimize switch table with -fPIE

2018-01-23 Thread thgarnie at google dot com
Assignee: unassigned at gcc dot gnu.org Reporter: thgarnie at google dot com Target Milestone: --- Created attachment 43225 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43225&action=edit Switch test case With -O2 and -fPIE switch tables are never optimized as well as the

[Bug target/82303] Better PIE/PIC code generation for kernel code (x86_64 & arm64)

2018-01-23 Thread thgarnie at google dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303 --- Comment #18 from Thomas Garnier --- Ok. Opened: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011

[Bug target/82303] New: Better PIE/PIC code generation for kernel code (x86_64 & arm64)

2017-09-22 Thread thgarnie at google dot com
rmal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: thgarnie at google dot com Target Milestone: --- The current PIE/PIC code generation is not optimal for kernel code. It makes inferences about the execution environment which do