similar to: [LLVMdev] Branch Relaxation Support?

ARM has its own pass to do this (ARMConstantIslandPass.cpp). At some point of time we'd like to rip out the branch relaxation part and make it into a target independent pass. Evan On Aug 13, 2009, at 10:02 AM, Bagel wrote: > I think I have read that there are plans to generate object code > (e.g. ELF) > directly in addition to assembly language source. If so, are there

On 02/16/2017 12:08 PM, Stephen Canon wrote: >> On Feb 16, 2017, at 9:12 AM, Bagel <bagel99 at gmail.com >> <mailto:bagel99 at gmail.com>> wrote: >> >> I figured that the optimization of this would bedifficult (else it would >> have already been done :-)) > > Don’t make this assumption. There’s lots of opportunities for optimization > scattered

> On Feb 21, 2017, at 9:54 PM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I believe that providing additional intrinsics that would directly produce the ISD::ADDC/ISD::SUBC nodes would provide the additional advantage of being able to directly produce these nodes for code that doesn't have anything to do with multiprecision addition/subtraction. I am

On 23 November 2010 18:03, Bagel <bagel99 at gmail.com> wrote: > Would someone be so kind as to tell me what the status of debugging symbols > (DWARF) generated by clang/llvm is? Hi Bagel, It should be fairly complete... > When I generate an executable with "clang -g" followed by "llc -O0" and feed it > to gdb, I get "no debugging symbols found".

Would someone be so kind as to tell me what the status of debugging symbols (DWARF) generated by clang/llvm is? I am on a linux x86-64 system (Fedora 13). Is gdb supposed to understand the generated DWARF? When I generate an executable with "clang -g" followed by "llc -O0" and feed it to gdb, I get "no debugging symbols found". What is the status of lldb on

On 12/03/2010 06:28 PM, Devang Patel wrote: > We are working on a document. Here is current draft: > http://wiki.llvm.org/Debug_Information > > - > Devang While this is great news, it doesn't completely satisfy my needs. Your documentation assumes one is going to use the LLVM provided functions (such as DIFactory::). My front-end can't use them because it is not

I am writing a backend for an experimental machine that has both 2-address and 3-address versions of some instructions. The 2-address versions are more compact and thus preferred when applicable. How does one go about generating the most compact version? 1. At instruction selection, is there a predicate that can test whether one of the input sources is dead, thus allowing the selection of the

On 09/11/2014 05:33 PM, Quentin Colombet wrote: > Hi Brian, > > On Sep 11, 2014, at 3:03 PM, Bagel <bagel99 at gmail.com> wrote: > >> When the IR specifies a 32 bit load can it be changed to a narrower >> load? What if the load is from memory (e.g. a peripheral) that only >> supports 32-bit access? Consider the following IR: ---- target datalayout >> =

Hi Tim, Thank you for your answer. *We've fairly recently fixed a bug that looks very similar (r238680,which was well after 3.6)* If I wanted to back port that to 3.5 where should I look at? Where in the ARM backend the decision to relax an instruction is taken? *That's weird. Even with "-filetype=obj" (the bug only occurs whendirectly writing an object file)? Not that it

When addresses are a displacement from a constant (this can happen in device drivers), the resulting address gets folded rather than using base+displacement addressing. This results in code bloat. Example test attached. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: const-addr.ll URL:

On 4 December 2010 21:16, bagel <bagel99 at gmail.com> wrote: > Perhaps you can add another section just on the textual format? Oh, perhaps you're looking for this: http://llvm.org/docs/SourceLevelDebugging.html cheers, --renato

On 08/20/2010 04:06 PM, Eli Friedman wrote: > On Fri, Aug 20, 2010 at 1:03 PM, Bagel<bagel99 at gmail.com> wrote: >> I propose a new intrinsic "llvm.memcmp" that compares a block of memory >> for equality (a subset of the libc behavior). Backends are free to use the >> alignment to optimize using wider than byte operations. Since the result is >> only

> This is starting to look very similar to how ARM constant islands work, without the extra ugliness from how small the ARM immediate displacements are. > > -Jim Would there be any reason that this couldn't be seen as an opportunity to move the constant islands pass out of the ARM backend and make the target-independent constant pools (which ARM bypasses completely) more generic?

On Feb 15, 2012, at 12:16 PM, Chris Lattner <clattner at apple.com> wrote: > > On Feb 14, 2012, at 10:30 AM, David Terei wrote: > >> Hmm writing a blog post about TNTC is beyond the time I have right now. > > Sure, understandable. I'm surprised someone else hasn't already :) > >> Here is some high level documentation of the layout of Heap objects

Now that there is good thumb2 support in the ARM backend, would someone please add "cortex-m3" to the "-march" list for the ARM backend. This should produce pure thumb2 only code. At some point, when the subsets are public, "cortex-m1" and "cortex-m0" should also be added. thanks, bagel

It takes two "llvm.uadd.with.overflow" instances to model the add-with-carry when there is a carry-in. Look at the IR generated by the example. I figured that the optimization of this would bedifficult (else it would have already been done :-)). And would this optimization have to be done for every architecture? On 02/15/2017 04:28 PM, Stephen Canon wrote: > > Why do you think

On Fri, Aug 20, 2010 at 1:03 PM, Bagel <bagel99 at gmail.com> wrote: > I propose a new intrinsic "llvm.memcmp" that compares a block of memory > for equality (a subset of the libc behavior).  Backends are free to use the > alignment to optimize using wider than byte operations.  Since the result is > only equal/not-equal, byte order is not important. > > For

On 12/06/2010 12:03 PM, Devang Patel wrote: > As I understand, you are not interested in 'how to use DIFactory'. Do you want > to know what are the fields of metadata to encode debug info for a local variable ? > That'd be > > !7 = metadata !{ > i32, ;; Tag (see below) > metadata, ;; Context > metadata, ;; Name > metadata, ;; Reference to

What assembler are people using with the SystemZ backend? I am trying to assemble the output of the SystemZ backend with the GNU binutils assembler (build with --target=s390x-linux). I get errors when assembling instructions with literals that are negatives. For example, the test case test/CodeGen/SystemZ/01-RetImm.ll gives errors: $ s390x-as 01-RetImm.s 01-RetImm.s: Assembler messages:

While implementing a MachineFunctionPass that runs as part of the ARMTargetMachine::addPreEmitPass(), I've run into a problem. This particular MFP can drastically increase the size (in MachineInstr count) of the MachineFunction that it processes, so much so that there is a real danger of pcrel calls and branches that use immediate offsets to not be sufficient. A naive test confirmed that