similar to: [LLVMdev] thumb2 folding of constant addresses unhelpful

I'm not authorized to file bugs. Would someone please enter this? Thank you, bagel Evan Cheng wrote: > Right. I am aware of this problem but am not sure about what to do about it. > It's common for a number 32-bit immediates in the same block with the same > lower or higher 16-bit. Since the immediates will not be split until late in > codegen, the target independent

The thumb2 instructions include unsigned and signed divide. Attached are a patch and test routine. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: div.diff URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091201/675cf4c5/attachment.ksh> -------------- next part -------------- An embedded and charset-unspecified text was

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 plans to support branch relaxation for targets which support long/short branch displacements? This is typically done in assemblers. thanks, bagel

OK, here's a patch that follows your suggestion. I'm not an authorized developer, so I can't commit it myself. The test case is also attached again. bagel Jim Grosbach wrote: > Ah, ok. I was comparing v7-A and v7-R only. The M3 is described in > separate documentation (mostly since it lacks the ARM mode instructions, > I suspect). In any case, as far as I can tell, not

I'm working with a Cortex-M3 core which is v7-M profile, and it has udiv and sdiv. bagel Jim Grosbach wrote: > Hello, > > As I understand it, the divide instructions are only available on the > v7-R profile of the v7 architecture. Is that incorrect? > > -Jim

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

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 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

Assume an architecture that has multiple condition code registers, e.g., powerpc. Now assume that there are predicate instructions like thumb2, but can specify which condition code register they refer to. Now also assume that these predicate instructions themselves are predicatible, if executed they change the current predication state. Can LLVM handle multiple levels of predication? When is

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

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

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 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".

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

On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote: > On 02/13/2017 02:42 PM, Waiman Long wrote: > > On 02/13/2017 05:53 AM, Peter Zijlstra wrote: > >> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote: > >>> That way we'd end up with something like: > >>> > >>> asm(" > >>> push %rdi; > >>>

On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote: > On 02/13/2017 02:42 PM, Waiman Long wrote: > > On 02/13/2017 05:53 AM, Peter Zijlstra wrote: > >> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote: > >>> That way we'd end up with something like: > >>> > >>> asm(" > >>> push %rdi; > >>>

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 >> =

The following causes an assertion in recent svn pulls, but not in 2.5. The assertion: llvm-as: /home/bgl/work/llvm-work/include/llvm/ADT/SmallVector.h:125: T& llvm::SmallVectorImpl<T>::operator[](unsigned int) [with T = llvm::Constant*]: Assertion `Begin + idx < End' failed. The .ll code: target datalayout =

Here is a one-line patch to support the cortex-m3. For those who plan the features for ARM, the new cortex-m0 implements only a subset of the Thumb2 instructions. I still have yet to see a document that details what's in the subset. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: arm.diff URL:

Anton Korobeynikov wrote: > Hello > "T2Divide" should be a subtarget feature bit. This way it can be > "automatically" assigned to the procesor. I agree this is a better approach. > The instruction selection patterns for t2{S,U}DIV should be also > guarded by this predicate. Is this necessary? Since the absence of the predicate causes lowering to expand