similar to: [LLVMdev] arithmetical operands signedness

Hi Jonas, > my target handles operands of multiplying instructions differently based on > signedness. since the result of a multiply doesn't depend on the signedness, I find it strange that your target differentiates between them. What I'm saying is that if you have (say) two i32 numbers a and b and you do a signed multiply: c = a *s b and an unsigned multiply d = a *u b

On 5 sept. 2011, at 17:48, Duncan Sands wrote: > since the result of a multiply doesn't depend on the signedness, I find it > strange that your target differentiates between them. What I'm saying is > that if you have (say) two i32 numbers a and b and you do a signed multiply: > c = a *s b > and an unsigned multiply > d = a *u b > then c and d are the same number

Hi Christophe, On 05/09/11 18:35, Christophe de Dinechin wrote: > > On 5 sept. 2011, at 17:48, Duncan Sands wrote: > >> since the result of a multiply doesn't depend on the signedness, I find it >> strange that your target differentiates between them. What I'm saying is >> that if you have (say) two i32 numbers a and b and you do a signed multiply: >>

Hi, As my target supports signed / unsigned interpretation of operands, I was a bit startled to find that the LLVM I/R does not express this info of the integer operands. I want to create an eg unsigned mul if the operands are unsigned, using an intrinsic. I find that with -g, metadata is generated which seems to convey this information. Is it safe to base this type of transformation on the

Hi I currently would like to find out the signedness of a instruction. But looking at the CBackend, it looks as if it is not that simple? So i have two questions: Is there an easier way than guessing as it is done in the CBackend? Is there a reason for that signedness is not part of the instruction type? Best regards ST

On Tue, Jun 3, 2008 at 2:42 AM, ST <st at iss.tu-darmstadt.de> wrote: > Hi > > I currently would like to find out the signedness of a instruction. But > looking at the CBackend, it looks as if it is not that simple? So i have two > questions: > Is there an easier way than guessing as it is done in the CBackend? > Is there a reason for that signedness is not part of the

Hello, Alberto. > I'm using llvm for instrumenting code, and I need to know if there's a way to > difference between signed and unsigned Values of integer type during an > optimization pass. Types are signless in LLVM 2, operations are not. So, you should probably inspect insts itself, not their operands. -- With best regards, Anton Korobeynikov. Faculty of Mathematics &

On Tue, 26 Jun 2007, [ISO-8859-1] Alberto González wrote: > The problem is that what i'm instrumenting is loads and stores, plus > function call arguments and return values, which have no signedness > information. Why do you need this? -Chris > El 26/06/2007, a las 17:03, Anton Korobeynikov escribió: > >> Hello, Alberto. >> >>> I'm using llvm for

The problem is that what i'm instrumenting is loads and stores, plus function call arguments and return values, which have no signedness information. El 26/06/2007, a las 17:03, Anton Korobeynikov escribió: > Hello, Alberto. > >> I'm using llvm for instrumenting code, and I need to know if >> there's a way to >> difference between signed and unsigned

I'm using LLVM to instrument C code to test the efectiveness of some methods of error detection with dynamic invariants (see http:// citeseer.ist.psu.edu/hangal02tracking.html). I'm using also a range invariant (max an min values seen). The problem is that for those invariants, I need to know if the value is signed or not (0xFF can be -1 or 255, depending on signed/unsigned).

On Tue, 26 Jun 2007, [ISO-8859-1] Alberto González wrote: > I'm using LLVM to instrument C code to test the efectiveness of some > methods of error detection with dynamic invariants (see http:// > citeseer.ist.psu.edu/hangal02tracking.html). I'm using also a range > invariant (max an min values seen). The problem is that for those > invariants, I need to know if the value is

Thanks Dylan, I am working on a backend which has mulhsu instruction that performs multiplication between signed and unsigned number and returns upper 32 bits into result register. I think I also need to write some code probably as you indicated to check signedness of the operands and based on that lower to mulhsu instruction. -Vivek On Mon, Feb 27, 2017 at 11:13 AM, Dylan McKay <me at

Dear all, I have an error in the simple prediction function for lm(). Maybe someone experienced the same? xma <- matrix(data = 0, nrow = 100, ncol = 2) xma[, 1] <- rnorm(100) xma[, 2] <- rchisq(100, df = 3) m1 <- lm(xma[, 1] ~ xma[, 2]) predict(m1, as.data.frame(seq(-13, 13, 0.5))) Thanks a lot, Trafim [[alternative HTML version deleted]]

Hello LLVMDevs, I am looking for an example for how to lower LLVM IR to mulsu kind of instruction. I found that AVR back end have such instruction but AVRInstrInfo.td does not define any DAG pattern for which this instruction gets emitted. def MULSURdRr : FMUL2RdRr<1, (outs), (ins GPR8:$lhs, GPR8:$rhs), "mulsu\t$lhs, $rhs", []>, Requires<[SupportsMultiplication]>; Also

Commit-ID: 8443e57e5ba71e462e31e3b5aad9f7dd1b4736f5 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=8443e57e5ba71e462e31e3b5aad9f7dd1b4736f5 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Tue, 5 Nov 2019 00:39:53 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Tue, 5 Nov 2019 00:44:32 +0000 [klibc] losetup: Fix char signedness

Hi all, I would like to start a thread on RoR related issues on the new Intel version of Mac OS X. I have been using Apple''s new iMac Core Duo (which comes with Intel version of Mac OS X) for about a week now. Here''s my experience: Ruby 1.8.4: It compiles albeit with many warnings. Most warnings were about "differ in signedness". It seems to work okay

gref->gref_id is unsigned so the error handling didn't work. gnttab_grant_foreign_access() returns an int type, so we can add a cast here, and it doesn't cause any problems. gnttab_grant_foreign_access() can return a variety of errors including -ENOSPC, -ENOSYS and -ENOMEM. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git a/drivers/xen/gntalloc.c

gref->gref_id is unsigned so the error handling didn't work. gnttab_grant_foreign_access() returns an int type, so we can add a cast here, and it doesn't cause any problems. gnttab_grant_foreign_access() can return a variety of errors including -ENOSPC, -ENOSYS and -ENOMEM. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git a/drivers/xen/gntalloc.c

gref->gref_id is unsigned so the error handling didn't work. gnttab_grant_foreign_access() returns an int type, so we can add a cast here, and it doesn't cause any problems. gnttab_grant_foreign_access() can return a variety of errors including -ENOSPC, -ENOSYS and -ENOMEM. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> diff --git a/drivers/xen/gntalloc.c

All, Please welcome Zhou Sheng <zhousheng00 at gmail.com> to the LLVM development community. Sheng is from Beijing and is a Masters student at the University there. Sheng and I will be working together on some significant changes to LLVM in the coming months. Our first task is to implement integer types without signs in LLVM. You can read Chris Lattner's notes on this change at this