[llvm-dev] i32 vs i32 signext for C int parameters to library functions

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Sat Sep 24 06:52:48 PDT 2016


----- Original Message -----
> From: "Eli via llvm-dev Friedman" <llvm-dev at lists.llvm.org>
> To: "Marcin Koƛcielnicki" <koriakin at 0x04.net>, llvm-dev at lists.llvm.org
> Sent: Wednesday, September 7, 2016 12:35:50 PM
> Subject: Re: [llvm-dev] i32 vs i32 signext for C int parameters to library functions
> 
> On 9/6/2016 4:10 AM, Marcin Koƛcielnicki via llvm-dev wrote:
> > To fix this bug, I need some way to tell whether to use i32 or i32
> > signext in target-independent LLVM passes - but none seems to exist
> > at
> > this moment.  I wrote a patch that adds this information to TTI (
> > https://reviews.llvm.org/D21739 ), but it doesn't fit with the
> > current
> > semantics of TTI - if the information about *ext is missing, we're
> > going to have correctness problems instead of merely lowered
> > performance.
> 
> The right answer here might be to put the information into
> TargetLibraryInfo.  Fundamentally, you're trying to answer something
> along the lines of "What's the correct signature for a call to
> memchr?".  This is the sort of question which TargetLibraryInfo
> already
> answers in other situations (for example, some standard libc
> functions
> have unusual names on some platforms).  If TargetLibraryInfo can't
> come
> up with the correct calling convention for a given function for
> whatever
> reason, it can just claim the function is unavailable, which
> preserves
> correctness.

I agree; TLI seems like the right place for this information.

 -Hal

> 
> -Eli
> 
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


More information about the llvm-dev mailing list