similar to: [LLVMdev] Signed/unsigned value type resolution

Hi All, I have question about 'isUnsignedDIType' function on 'llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp' When we want to generate object file with dwarf debug format, clang can generates 'DW_ATE_lo_user' encoding for complex integer type as follow: "clang/lib/CodeGen/CGDebugInfo.cpp" llvm::DIType *CGDebugInfo::CreateType(const ComplexType *Ty) { ... if

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

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

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

+llvm-dev which got lost somehow > -----Original Message----- > From: Robinson, Paul > Sent: Thursday, March 31, 2016 10:33 PM > To: 'jingu kang' > Subject: RE: [llvm-dev] Question about 'isUnsignedDIType' function on > DwarfUnit.cpp > > > > > -----Original Message----- > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On

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

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 2013 Nov 15, at 19:41, Mark Lacey <mark.lacey at apple.com> wrote: > I don’t have the C/C++ standards in front of me but IIRC whether a char/short/int/long/long long bitfield is signed or unsigned is implementation defined. You need to explicitly specify signed or unsigned in order to have any guarantee of the signedness, e.g. signed int. Section 3.9.1 of the C++11 standard [1]

C says that plain bit-fields could be either signed or unsigned. C++ removed this allowance in core issue 739: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#739 On Sat, Nov 16, 2013 at 1:55 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > On 2013 Nov 15, at 19:41, Mark Lacey <mark.lacey at apple.com> wrote: > > > I don’t have the C/C++

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

On Nov 15, 2013, at 3:42 PM, Kay Tiong Khoo <kkhoo at perfwizard.com> wrote: > I've been diagnosing this bug: > http://llvm.org/bugs/show_bug.cgi?id=17827 > > Summary: I think the following program miscompiles at -O1 because the fact that 'f0' is a signed 3-bit value is lost in the unoptimized LLVM IR. How do we fix this? I don’t have the C/C++ standards in front

gcc -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-builtin -msoft-float -I../../../tools/include -I. -c -o hvmloader.o hvmloader.c cc1: warnings being treated as errors

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

> there is no such information. You can still consider every type to have values > in, say, T = [-2^31; 2^31-1]. Probably you are trying to deduce an interval of > possible values for each register. You will need to allow intervals to wrap > around the end of T since (eg) the basic "add" operator in LLVM uses modulo > arithmetic, i.e. if you add 1 to 2^31-1 you get

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, APFloat::fusedMultiplyAdd currently computes the wrong signed zero when small negative results are truncated back to zero in standard precision. The following snippet handles the signedness in fusedMultiplyAdd: /* If two numbers add (exactly) to zero, IEEE 754 decrees it is a positive zero unless rounding to minus infinity, except that adding two like-signed zeroes gives that

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