search for: stewartd

...ail.com] Sent: Friday, May 30, 2014 3:58 PM To: Daniel Stewart Cc: LLVM Developers Mailing List Subject: Re: Error with Gold Linker during LTO Sorry, I had understood that the linker was crashing, not the generated program. I can reproduce the issue now. On 30 May 2014 15:48, Daniel Stewart <stewartd at codeaurora.org> wrote: > So you see the issue as well in ARM? When doing a > > objdump -D weakMainO1.exe | grep -A 10 "<_ZN1C13caller_methodEv>:" > > I see: > > 00008b88 <_ZN1C13caller_methodEv>: > 8b88: e92d4800 push {fp, lr}...

When using the ARM cross compiler we've run into an issue with LTO and optimized libraries. Consider you have an optimized library opt.a, which contains a version of memcpy. Compiling with LTO (something like), clang myTest.c opt.a -flto -o myTest causes myTest.c to get compiled to bitcode. Then the bitcode gets passed to the linker. The linker looks through the bitcode (via

"Daniel Stewart" <stewartd at codeaurora.org> writes: > I'm no expert on the PassManager, but I happen to be going through it > fairly carefully right now. You didn't state which passes were Module > Passes and which were Function Passes (or other types). Sorry, I did mean to include that. They are all...

Looking at the existing flow of passes for LTO, it appears that most all passes are run on a per file basis, before the call to the gold linker. I'm looking to get people's feedback on whether there would be an advantage to waiting to run a number of these passes until the linking stage. For example, I believe I saw a post a little while back about postponing vectorization until the

So you see the issue as well in ARM? When doing a objdump -D weakMainO1.exe | grep -A 10 "<_ZN1C13caller_methodEv>:" I see: 00008b88 <_ZN1C13caller_methodEv>: 8b88: e92d4800 push {fp, lr} 8b8c: e1a0b00d mov fp, sp 8b90: e24dd008 sub sp, sp, #8 8b94: e58d0004 str r0, [sp, #4] 8b98: e59d0004 ldr r0, [sp, #4] 8b9c: ebffdd17 bl 0

...I; })) { ... After ignoring load/stores which satisfy something like the above code, you can always fallback to the current code of choosing an integer type, so in the common case there won’t be any behavior difference. Cheers Pete On Apr 21, 2015, at 9:18 AM, Daniel Stewart <stewartd at codeaurora.org <mailto:stewartd at codeaurora.org> > wrote: So this change did indeed have an effect! :) I’m seeing regressions in a number of benchmarks mainly due to a host of extra bitcasts that get introduced. Here’s the problem I’m seeing in a nutshell: 1) There is...

I'm trying to understand why using a local memcpy with LTO results in a "multiple definition" error. I have an local (optimized) mempy.c (clearly simplified!): void* memcpy(void* dest, const void* src, unsigned int count) { return 0; } void* __aeabi_memcpy(void *dest, const void *src, unsigned int size) { return memcpy(dest,src,size); } --- I also have a simple

Hi Jakob, You're the unfortunate soul who last touched the constant island pass, right? Do you happen to have any insight for Daniel? Chad On Tue, Jul 23, 2013 at 9:55 AM, Daniel Stewart <stewartd at codeaurora.org>wrote: > In looking at the code in > ARMConstantislandPass.cpp::optimizeThumb2JumpTables(), I see that there is > the following condition for not creating tbb-based jump tables:**** > > ** ** > > // The instruction should be a tLEApcrel or t2LEApcrel...

...soul who last touched the constant island pass, right? Do you happen to have any insight for Daniel? Sorry, no. I don't remember working with that particular bit of code. You could try digging through the commit logs. Thanks, /jakob > On Tue, Jul 23, 2013 at 9:55 AM, Daniel Stewart <stewartd at codeaurora.org> wrote: > In looking at the code in ARMConstantislandPass.cpp::optimizeThumb2JumpTables(), I see that there is the following condition for not creating tbb-based jump tables: > > > > // The instruction should be a tLEApcrel or t2LEApcrelJT; we want >...

I've been implementing ELF/AArch64 support for lld. I can now successfully link and run a simple "Hello World" app for both dynamic and static linking. I'd like to upstream this implementation, but wanted to get feedback on how people might like to see it. Would people rather see the whole thing in one shot, each file individually or somehow break it down even farther? The

In looking at the code in ARMConstantislandPass.cpp::optimizeThumb2JumpTables(), I see that there is the following condition for not creating tbb-based jump tables: // The instruction should be a tLEApcrel or t2LEApcrelJT; we want // to delete it as well. MachineInstr *LeaMI = PrevI; if ((LeaMI->getOpcode() != ARM::tLEApcrelJT &&

So this change did indeed have an effect! :) I’m seeing regressions in a number of benchmarks mainly due to a host of extra bitcasts that get introduced. Here’s the problem I’m seeing in a nutshell: 1) There is a Phi with input type double 2) Polly demotes the phi into a load/store of type double 3) InstCombine canonicalizes the load/store to use i64 instead of double 4)

"Daniel Stewart" <stewartd at codeaurora.org> writes: > You haven't mentioned if your passes are implementers of an interface > (like AliasAnalysis). No, they're just regular FunctionPasses. > What seems to matter as far as having a pass free'd from memory are > the LastUsers. The LastUsers are...

I'm looking at an issue where we want a particular pseudo-instruction to choose from a set of registers that is not included in the existing set of RegisterClass definitions. More concretely, there is a RegisterClass in ARMRegisterInfo.td defined as def rGPR : RegisterClass<"ARM", [i32], 32, (sub GPR, SP, PC)> { let AltOrders = [(add LR, rGPR), (trunc rGPR, 8)]; let

We've found an error during the use of LTO that appears to happen only during the use of the gold linker. We essentially have a file which is compiled *without* LTO: f1() { h1(); } And a second file that is compiled/linked *with* LTO: f2() { f1(); h1(); } This second file has the function h1() inlined during LTO. The resulting executable fails because the symbol for h1

...en; it does happen though: e.g. I have been in a situation where a benchmark surprisingly goes 50% faster on about 1/10 runs). When working across different programs, you are almost always in a "lab assistant" situation. -- Sean Silva On Mon, Dec 15, 2014 at 11:27 AM, Daniel Stewart <stewartd at codeaurora.org> wrote: > > I have done some preliminary investigation into postponing some of the > passes to see what the resulting performance impact would be. This is a > fairly crude attempt at moving passes around to see if there is any > potential benefit. I have attached...

Ok, I've been struggling with this for two days and hopefully someone can help me out. I have a set of passes, analysis passes A, B, C, D and transformation passes E and F. Pass C depends on pass A and pass D depends on pass B. Pass E depends on C and D and does not preserve any analysis pass. Pass F depeds on pass A and pass C. Pass F runs after pass E. Graphically the dependency graph

I've been adding ELF/AArch64 support to lld based off the existing x86_64 code that is already there in lld. I've been able to compile and link a simple "Hello World"-type program. However, I'm getting what appears to be a misplacement/name change of the _start atom. When I do the link, the _start section gets named __tls_get_addr. The code inside this section appears to be