similar to: [LLVMdev] signedess of operands

Hi, I have worked with GCC prior to using LLVM, and I am a bit startled to find no way to use an earlier operand as is done in GCC. For example, a sext instruction on my target takes one the operand of a low-part register, and then sign extends into the full register.I find that there is no way to use for example (set RC:$srsc, sext($src, 16)), or in any other way use a sext operator to perform

Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 24.04.2013 23:47:54: > I would like to add one more case here: Fixed register operands. > > Some instructions, like x86's MUL and DIV, take operands in fixed > registers. Currently, we handle that with COPY instructions to and > from the fixed registers, but that is making code motion passes more > complicated than

Hi there, I''ve got the following problem on my hand..... I''m a sysop for a school in the netherlands. We have a network with 5 different schools (and 1 administration). Each of those have their own ip range in the private network (10.4.0.0 10.5.0.0 and so on). For all these schools we have an internet uplink of 2mbit. And this bandwidth should be shared as fairly as possible.

Hi, my target handles operands of multiplying instructions differently based on signedness. I wonder then how I would do instruction selection based on the operands signs? The mul instruction sets a nsw for signed, but when i try unsigned ops, there is no wrap flag at all. I'm not sure this is enough information to work with, or? Jonas -------------- next part --------------

On Apr 25, 2013, at 4:44 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 24.04.2013 23:47:54: > >> I would like to add one more case here: Fixed register operands. >> >> Some instructions, like x86's MUL and DIV, take operands in fixed >> registers. Currently, we handle that with COPY

On Apr 23, 2013, at 11:06 AM, Jim Grosbach <grosbach at apple.com> wrote: > There are two core issues. First, the tied operands are an artifact of the way we do instruction selection for the compiler. They’re how we represent read-modify-write operands, basically. The assembler shouldn’t have to know or care about them at all. Specifically, they shouldn’t even be represented at all as an

Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 25.04.2013 18:58:05: > On Apr 25, 2013, at 4:44 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote: > > > Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 24.04.2013 23:47:54: > > > >> I would like to add one more case here: Fixed register operands. > >> > >> Some

Hi, Two-address instructions are represented as normal three-address instructions with a Desc bit that indicates the first two operands are tied together. The question is, should the second operand have a <kill> flag? a: %R0<def> = MUL %R0, %R1<kill> b: %R0<def> = MUL %R0<kill>, %R1<kill> I think the current policy is a: There should be no kill-flag.

> That makes sense, and I think for "direct" values in your definition it is true that all direct values are r-values. > Why do we need DW_OP_LLVM_direct when we already have DW_OP_LLVM_stack_value? Can you give an example of something that is definitely not a stack value, but direct? The difference in definition is the intention: DW_OP_LLVM_direct means "we'd like this

Hi, I am trying to complete the hardware multiplier option for MSP430 backend. As the hardware multiplier in most of the MSP430 devices is for i8 and i16 operands, with i16 and i32 result, I am lowering MUL_i8 and MUL_I16. However, the front-end promotes the i8 argument to i32, executes 32-bit multiplier and truncates to 16-bit, so I never lower MUL_I8 nor MUL_I16 but MUL_I32, wchich is lowered

Hello all: I apologize for what I imagine is a rather silly question, but I'm still somewhat new to LLVM and am stuck. I am reworking some code that was originally in the backend involving MachineInstructions and MachineOperands, and I now need for it to function as an LLVM IR pass, using just Instructions, etc, and nothing related to 'Machine'. However, I am not sure how to get the

I have written many builtins for our SHAVE processor which bind directly to our instructions, and making instructions that are not easily selectable by the compiler available to the programmer. The majority of these are straight-forward enough, taking a small number pf input operands and returning a single result; for example 'int __builtin_shave_mul(int, int)' might map onto a simple

Hi All, I replaced a Linux file server at a company last month. Both server had to be active at the same time to transition, so the new server got a new name. The customer client computers are all XP still. The machine with the client UPS World Ship stopped working as it kept looking for the old server. I replaced every instance of the old server's name with the new server in the registry.

On Jun 2, 2011, at 9:46 AM, Griffin Wright wrote: > > Hello all: > > I apologize for what I imagine is a rather silly question, but I'm still > somewhat new to LLVM and am stuck. I am reworking some code that was > originally in the backend involving MachineInstructions and > MachineOperands, and I now need for it to function as an LLVM IR pass, > using just

I was scanning through my config.h and noticed something that startled me a bit. The configure script actually checks what sizeof(char) is, and defines.h relies on this information. This is completely unnecessary. By definition, sizeof(char) is always 1. This is not a matter of opinion; the C standard explicitly states, in ?6.5.3.4 alinea 3, When applied to an operand that has type char,

Hi, is it possible to reduce link time by excluding unused target backends? I would like to type tools/llc make -target=... , and just build it for one backend. /Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110311/c2179915/attachment.html>

You probably meant to send this to LLVMdev as well. Begin forwarded message: Date: Mon, 29 Nov 2010 08:26:03 +0100 From: Jonas Paulsson <jnspaulsson at hotmail.com> To: <edwintorok at gmail.com> Subject: RE: [LLVMdev] LLVMdev Digest, Vol 77, Issue 41 Yes, the new type is simply a static object managed by Type and LLVMContext. This is only referred to by Values of fixed point type.

Hi Adrian & Stephen, One thought here: But — not all memory locations are l-values. If we have a DWARF location list for variable "x" which points to a memory address for the first n instructions and the switches to a constant for the remainder of the scope, the memory address is not guaranteed to be an l-value, because writing the the memory address cannot affect the later part of

<retitling to be useful> LLVM shouldn't have a fixed point type class. You should just use standard integer types. Supporting fixed point and saturation should by done by adding new operations to llvm IR. If you're interested in this, I'd suggest starting by implementing these as intrinsics. If it makes sense over time we can change them to primitive instructions if there is

Jonas Paulsson <jnspaulsson at hotmail.com> writes: > is it possible to reduce link time by excluding unused target backends? > > I would like to type > > tools/llc make -target=... , and just build it for one backend. If you build with configure && make, use the configure option --enable-targets. If you build with cmake && make, pass