similar to: [LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values

On 22 October 2012 14:53, Chandler Carruth <chandlerc at google.com> wrote: > So, I'm not really sure if this is the right approach. I'd like some > folks from the LLVM side of things to chime in. > > In general, I'm not certain we want to continue growing our dependence > on the signext and zeroext attributes on return types, or whether we > want to do the

On 22/10/12 21:12, Rafael Espíndola wrote: > On 22 October 2012 14:53, Chandler Carruth <chandlerc at google.com> wrote: >> So, I'm not really sure if this is the right approach. I'd like some >> folks from the LLVM side of things to chime in. >> >> In general, I'm not certain we want to continue growing our dependence >> on the signext and

Chandler Carruth <chandlerc at google.com> wrote on 22.10.2012 20:53:54: > So, I'm not really sure if this is the right approach. I'd like some > folks from the LLVM side of things to chime in. > > In general, I'm not certain we want to continue growing our dependence > on the signext and zeroext attributes on return types, or whether we > want to do the

----- Original Message ----- > From: "Duncan Sands" <baldrick at free.fr> > To: "Rafael Espíndola" <rafael.espindola at gmail.com> > Cc: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>, "llvm cfe" <cfe-commits at cs.uiuc.edu>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu> > Sent: Tuesday,

In SelectionDAGBuilder::visitRet(), there is this bit of code: // FIXME: C calling convention requires the return type to be promoted // to at least 32-bit. But this is not necessary for non-C calling // conventions. The frontend should mark functions whose return values // require promoting with signext or zeroext attributes. if (ExtendKind !=

Hello, For a simple function taking a short and returning a short, clang generates IR with this function signature: define signext i16 @foo(i16 signext %x) Some questions please: 1) For the input parameter and return value, does the target control whether clang uses signext vs something else? If so, how does this target query work? 2) Does the presence of the signext mean it's imperative

Hi, What are the intended semantics of noalias when applied to a vector of pointers? signext/zeroext parameter attributes are incorrectly rejected for vectors (bug 15391), and I'm not sure if the same is true for noalias when applied to pointer vectors. There's no mention of it in the langref, and the verifier currently rejects it. Is it supposed to work? Are pointers within the

Hi, > What we are trying to do is to add new attributes (more maybe added > later): > > > sign_ext_from_i8, sign_ext_from_i16 > > zero_ext_from_i8, zero_ext_from_i16 > > to function definition so (assuming that both caller and callee are > generated in the same front-end) the caller will know if the callee has > already extended the return value or not, then

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Steve King > Sent: 23 July 2015 01:45 > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] signext on function parameters and return. > > Hello, > For a simple function taking a short and returning a short, clang > generates IR with this function

Hi Duncan, thanks for the hint. I tried both variants: define <4 x float> @masked_add_1(<4 x i1> signext %mask, <4 x float> %a, <4 x float> %b) define <4 x float> @masked_add_32(<4 x i32> %mask, <4 x float> %a, <4 x float> %b) Unfortunately, this will raise an assertion: Wrong types for attribute: zeroext signext noalias nocapture sret byval nest

On Mar 16, 2011, at 5:58 AM, Ken Dyck wrote: > In SelectionDAGBuilder::visitRet(), there is this bit of code: > > // FIXME: C calling convention requires the return type to be promoted > // to at least 32-bit. But this is not necessary for non-C calling > // conventions. The frontend should mark functions whose return values > // require promoting

On Mar 31, 2009, at 12:04 PM, Rafael Espindola wrote: >> Did you see this Ali? >> http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt > > Would you mind adding it to SVN? Would make it easier > to comment on. In particular, it would be nice to add > examples for X86 (caller extends. High bits undefined > in the callee) and PPC (callee extends). Sure, I checked

On Wed, Mar 16, 2011 at 12:35 PM, Cameron Zwarich <zwarich at apple.com> wrote: > On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote: > >> Promoting the return value is unsafe for bool returns on x86-64, which >> in the latest revision of the ABI only guarantees that the top 7 bits of >> the 8-bit register are 0. > > My comment is a bit off, because the question

Hi, I noticed that when dividing with signed 8-bit values the IR uses a 32-bit signed divide, however, when unsigned 8-bit values are used the IR uses an 8-bit unsigned divide. Why not use a 8-bit signed divide when using 8-bit signed values? Here is the C code and IR: char idiv8(char a, char b) { char c = a / b; return c; } define signext i8 @idiv8(i8 signext %a, i8 signext %b) nounwind

Do you actually have a use case for such attributes, or are you just trying all possible attributes on all possible types to see what breaks? ;-) It would be theoretically possible to define semantics for signext/zerext or even noalias for vectors. However it's not clear whether those are really desirable without motivating use cases. Dan On Wed, Sep 4, 2013 at 2:31 PM, Matt Arsenault

Hi Sanjay, thank you a lot for your answer. I understand that in your examples it is desirable that `foo` and `goo` are canonicalized to the same IR, i.e., something like `@goo`. However, I still have a few open questions, but please correct me in case I'm thinking in the wrong direction. > Am 21.07.2016 um 18:51 schrieb Sanjay Patel <spatel at rotateright.com>: > > I've

Some targets want to do the promotion in the callee and some in the caller. Now what you are discussing in your bug is we shouldn't do in both... Now the tricky part is that many targets (not for the sake of promotion, but for the sake of performance) return a smaller value in a larger register (say if the function is to return char, they return it in 32 bit register); So they are effectively

Ok, here is the patch again... I also included fixes for the bits that originally gave my mailer fits... Two votes for orange, so I went with orange... Doing diffs in .: --- ./lib/AsmParser/LLLexer.cpp.~1~ 2007-12-14 22:09:06.000000000 -0800 +++ ./lib/AsmParser/LLLexer.cpp 2007-12-15 13:02:47.000000000 -0800 @@ -54,7 +54,7 @@ static uint64_t HexIntToVal(const char * Result +=

Hi all, due to the recent changes regarding paramater/function/return type attributes, I think the documentation around that could use some improvement. In particular, I see the following problems: * The section "Functions" in the LangRef has a large textual description about how it should look, but no definition of syntax, or even a few examples of the syntax. This makes it very

I'm trying to fix a longstanding bug with library function calls on platforms where int is passed sign-extended in a register (it badly affects SystemZ, and has a chance of affecting PowerPC64, SPARC64, MIPS64 as well). The problem is that, on these platforms, C int corresponds to a "i32 signext" parameter, but all LLVM passes inserting library calls currently use just