similar to: [LLVMdev] [lld] question on ELF section formating

Hello, Depending on how I extract integer lanes from an x86_64 xmm register, the backend may spill that register in order to load scalars. The effect was observed on two targets: corei7-avx and btver1 (I haven't checked other targets). Here's a test case with spilling/no-spilling code put on conditional compile: #if __SSE4_1__ != 0 #include <smmintrin.h> #else #include

Hi, Checking the llvm test-suite SingleSource/Regression/C++/EH/class_hierarchy testcase on aarch64 I noted something strange: Dump of assembler code for function _Z4funcj: 0x0000000000400650 <+0>: stp x22, x21, [sp,#-48]! 0x0000000000400654 <+4>: stp x20, x19, [sp,#16] 0x0000000000400658 <+8>: stp x29, x30, [sp,#32] 0x000000000040065c

Looks like it is also not working on x86_64, using clang/lld I am seeing a segmentation fault: Dump of assembler code for function _Z4funcj: 0x0000000000400590 <+0>: push %rbp 0x0000000000400591 <+1>: push %rbx 0x0000000000400592 <+2>: push %rax 0x0000000000400593 <+3>: mov %edi,%ebp 0x0000000000400595 <+5>: pop %rdx 0x0000000000400596

Hi, For the following code: void foo (); int main () {foo();} llvm emits "bl foo" Then I set foo at a far address in linking: aarch64-linux-gnu-gcc -Wl,--defsym=foo=0x80000000 a.o -o a.exe I got an error from ld: a.c:(.text+0x8): relocation truncated to fit: R_AARCH64_CALL26 against symbol `foo' define in *ABS* section in a.exe The question is: do I

I'd like to convert the following call A at GDPLT //R_HEX_GD_PLT_B22_PCREL to call __tls_get_addr //R_HEX_B22_PCREL "A" is a TLS variable and preceding code has prepared for the call. When the R_HEX_GD_PLT_B22_PCREL is found it will initially point to the TLS variable so at that point I'd like to define a __tls_get_addr symbol and update the relocation's type and symbol

I updated a powerpc64 be system from fedora 25 (glibc 2.24) to fedora 26 (glibc 2.25) and several test cases started failing that deal with dynamic thread local storage. Failing Tests (3): LeakSanitizer-AddressSanitizer-powerpc64 :: TestCases/Linux/use_tls_dynamic.cc LeakSanitizer-Standalone-powerpc64 :: TestCases/Linux/use_tls_dynamic.cc MemorySanitizer-POWERPC64 ::

Hi, I've encountered a newly introduced bug in lld today. I am building my program with clang and lld on an X86-64 Ubuntu Linux machine. Command line: clang main.c The compiled program invokes the "main" function multiple times until it closes with a segmentation fault. This affects even the most primitive programs like "int main() { return 0; }". The problem

>> Do you know what is the rationale for that? The static linker will >> optimize it anyway (but not do as good a job as the compiler could). > > codegen can be more efficient. E.g. less or no calls to __tls_get_addr > needed. My point also :-) What I was asking for a rationale on was *not* doing the optimization in the compiler. > Joerg Cheers, Rafael

On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers wrote: > On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote: > > > > 8.0.0-rc1 was just tagged (from the branch at r351980). > > > > It took a little longer than planned, but it's looking good. > > > > Please run the test

On Thu, Oct 31, 2019 at 11:17 AM Jorg Brown via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Oct 31, 2019 at 8:50 AM kamlesh kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Devs, >> Consider testcase here >> https://godbolt.org/z/qHZzqw >> When optimization is O1 or above it produces unoptimized code >> because it

On Tue, Jun 12, 2012 at 10:41:37AM -0400, Rafael Espíndola wrote: > > I thought it was a good idea to make the user's choice explicit in the > > IR. If we combined the default and globaldynamic modes, LLVM wouldn't > > be able to tell the difference. > > > > It may or may not be important to be able to tell the difference, but > > it would be unfortunate

On Tue, Jun 12, 2012 at 12:36:28PM -0400, Rafael Espíndola wrote: > >> Do you know what is the rationale for that? The static linker will > >> optimize it anyway (but not do as good a job as the compiler could). > > > > codegen can be more efficient. E.g. less or no calls to __tls_get_addr > > needed. > > My point also :-) What I was asking for a

Hi Devs, Consider testcase here https://godbolt.org/z/qHZzqw When optimization is O1 or above it produces unoptimized code because it calls __tls_get_address in loops. While with optimization disabled It produce single call to __tls_get_address outside of loop. is this a missed optimization by llvm? ./Kamlesh

https://bugzilla.mindrot.org/show_bug.cgi?id=866 Josh Triplett <josh at freedesktop.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |josh at freedesktop.org --- Comment #13 from Josh Triplett <josh at freedesktop.org> 2008-01-03

On Tue, Jun 12, 2012 at 7:05 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Tue, Jun 12, 2012 at 12:36:28PM -0400, Rafael Espíndola wrote: >> >> Do you know what is the rationale for that? The static linker will >> >> optimize it anyway (but not do as good a job as the compiler could). >> > >> > codegen can be more efficient. E.g.

> I thought it was a good idea to make the user's choice explicit in the > IR. If we combined the default and globaldynamic modes, LLVM wouldn't > be able to tell the difference. > > It may or may not be important to be able to tell the difference, but > it would be unfortunate if we'd have to go and change the IR format > later because we limited ourselves here.

A few days ago, I tried to change the optimization flag from -O0 to -O2 to speed up the execution of the application on Ubuntu/ARM 14.04 32 bit. When I compiled the source code with -O2 flag instead of -O0 flag, I could not run the application normally by getting always the segmentation fault. Here is debugging information with GDB command in case of that. As you can see, we could not execute

https://bugzilla.mindrot.org/show_bug.cgi?id=1427 Summary: scp -q behavior different than documented Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P3 Component: scp AssignedTo: bitbucket at mindrot.org

Hello Clang and LLVM Devs, I have been working to add support for an attribute in clang and LLVM that helps user to guide interprocedural register allocation. But the use case I am having is very limited and thus I belieave it is good to have discussion on this before sending a patch. So for IPRA we have a situation where a function is calling a function which is written in assembly and it is

On Wednesday 09 December 2009 13:42, Anton Korobeynikov wrote: > Hello, David > > >> Don't do that (tm) > > > > Why not? > > They will be eliminated w/o any visible effect. Hmm...As I said I added them in our 2.5 implementation and they didn't get eliminated. The stack gets properly adjusted and everyone's happy. Our 2.5 implementation creates the