similar to: Unsigned int displaying as negative

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

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

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

Right, I understand that. So why is 0x7FFF matching fine but not 0x8000 both fit in 16 bit? Thanks. On Wed, Feb 15, 2017 at 1:24 PM, Reid Kleckner <rnk at google.com> wrote: > LLVM IR integers have no sign. You can't reliably tell whether an add or > subtract was signed or unsigned when generating code. > > On Wed, Feb 15, 2017 at 10:19 AM, Ryan Taylor via llvm-dev <

Tim, yes, I am on a very unique architecture, just about every instruction has a signed and unsigned operation (ie, adds, addu, subs, subu, etc...) and we handle signed and unsigned somewhat differently. I'm not sure how we'll handle this yet, very worst case scenario is to propagate the info from clang but that's not ideal, obviously. Thanks for all the replies! On Wed, Feb 15,

Tim, The issue is saturation is treated differently for signed than it is for unsigned. Ryan On Thu, Feb 16, 2017 at 9:49 AM, Tim Northover <t.p.northover at gmail.com> wrote: > On 15 February 2017 at 17:02, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Tim, yes, I am on a very unique architecture, just about every > instruction > > has a signed and unsigned

On Wed, Mar 30, 2011 at 03:19, Julien Henry <Julien.Henry at imag.fr> wrote: > > Actually, I'm working on a static analyzer that computes invariants at > each basicBlock: "In basicBlock B, what is the set of possible > assignments for each live values ?" > and I obtains results such as "In B, we have 0 <= x <= 42" > Well, you have to find that

>> The compiler remembers for debugging purpose that x is defined as >> unsigned, and y as signed, no ? I'm not familiar with LLVM debug info, >> but maybe I can find this info there ? > > probably it can be extracted from debug info, but what if there is no debug > info? Can you please explain what you intend to do with this information - > then maybe we can

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

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

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 Mar 6, 2011, at 01:22, Erik de Castro Lopo wrote: > Brian Willoughby wrote: >> Hopefully, libsndfile no longer uses the incorrect 0x7FFF (32767) >> factor for float to 16-bit integer conversions, because that would >> make it unacceptable for lossless file conversions. > > That is a statement of opinion rather than fact but I won't go into > that here. It is

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

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

Thanks for replying. actually 2^15 in decimal is the same as 0x8000 in hex. the idea is clear for me that i should scale down each unsigned sample by 0x8000 for becoming signed. I hope that will work correctly as input raw samples to Speex codec. do you think so ? Regards, Mash'al ________________________________ From: Steve Checkoway <s at pahtak.org> To: Mashal al-shboul

Hi everybody, I have been using speex-1.2beta1 and my input data is 8-bit unsigned so I know that I should convert from 8 to 16 bits. I've done the convertion as following. for(int i=0; i<160; ++i) { input_frame[i] = (short)( (data[2*i] << 8) | data[2*i+1]); } When my codec application didn't work right, I think that the reason is an error at this

Hi Julien, > For an function's argument of type T, at the beginning of my analysis, I > consider its set of possible values is all the set of all elements of > type T. > In the case of an int, it is [-2^31; 2^31-1], whereas it is [0, 2^32-1] > for an unsigned... > That's the reason why I was searching in the llvm bitcode something > distinguishing these two types.

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, Oct 13, 2020 at 10:47 AM Madhur Amilkanthwar <madhur13490 at gmail.com> wrote: > What do you guys think about the below enhancements? > > 5. !getdagrestype(dag [, index]) - Returns type of result value. If the DAG computes multiple values then return type of 'index'th result. > > 6. !setdagrestype(dag target_dag, type T [, index]) - Set return type of

On Oct 12, 2008, at 22:32, Paul Davis wrote: > On Sun, 2008-10-12 at 19:26 -0700, Brian Willoughby wrote: >> Is anyone here potentially up to the task of adding support for CAF >> (the CoreAudio Format) into the flac command-line? This would >> present minimal difficulty under OSX, due to the presence of the >> CoreAudio API, but the real challenge would be to support