similar to: [LLVMdev] signedness of types

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

Where does the unsignedSub come from? On 2017-02-15 20:38, Ryan Taylor wrote: > Sorry, it should be: > > defm SUB16u_ : ABD_NonCommutative<"sub16u", unsignedSub, LOADRegs, > GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>; > > On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> > wrote: > >> I see. If I put simm16 and

Thanks for your reply. We are propagating sign info to tablegen currently using BinaryWithFlagsSDNode.Flags.hasNoSignedWrap atm. I imagine (I have not looked) they are printed according to instruction in AsmPrinter.cpp (pure speculation). I'm still confused as to why 0x7FFF is ok to match 16 bit int but not 0x8000? Thanks. On Wed, Feb 15, 2017 at 1:44 PM, Manuel Jacob <me at

I see. If I put simm16 and immSExt16x in place of uimm16 and immZExt16x respectively, the imm matches but it prints out -32768 (which is invalid for sub16u). We are using uimm16 not match unsigned but for PrintMethod, effectively uimm16 and simm16 are both Operand<i16>. I'm still unclear why simm16 matches and uimm16 does not. Here is the pattern if that helps at all. So just as a

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

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

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

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

Hi all, I am currently working on a static analysis aimed at integer arithmetic overflow/underflow detection. We are attempting to build a sound abstract domain (based on Cousot & Cousot-style abstract interpretation), but practically speaking this really requires the ability to figure out the word size and signedness of values in the intermediate representation. I'm well aware

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

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

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 &

> I'm periodically updating my local version of the LLVM, and, when I did it > today, I couldn't use the llc with -march=c. Looking for the CBackend files, > I realized that they were removed from the LLVM folder. I actually don't > remember reading about a drop of this capability in any of the devlist > messages, so I was wondering if this removal could be only

Hi all I am just about to start a project using rails and am trying to setup my enviroment with postgres as the database. I have installed postgres 8.3.1 from source and am now having trouble installing the ruby- postgres gem. The following is the output trace I am getting, looks like a problem with headers/includes, any help is greatly appreciated. Thanks Simon sudo gem install ruby-postgres

I'm curious why 'unsigned short w = 0x8000' is displayed as -32768 in the IR? This propagates to the DAG and hence tablegen, where I am missing matching on some immediates because the immediate is not being looked at as unsigned? For example, we have no issue if instead of 0x8000 we use 0x7FFF, then everything is fine, the match is fine. I can understand that it's just being

Dear Jim and Owen, Thanks for replies, I only kindly suggest some discussion on the maillist in such cases. Just in general, nasty precedents sometimes happen, for example on IRC I've recently seen some commits to Objective C were requested to be reverted, because they were commited without any discussion. Here things are certainly not that hard, but the point is the same: it is always nice

Hi, I have a version of the old CBackend which is working with the current trunk. I am in the progress of rewriting it into a new version but that project is not going as fast as I would hope as I have been distracted by other tasks with higher priority lately. Anyway, for those interested, I can provide patches, optionally separated into several parts (core, testing, misc). I am afraid that

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