similar to: Changing the libc calling convention

Tim, Are you referring to setLibcallName? That is target specific yes but there isn't RTLIB for most of the libm functions, for example, for acos this doesn't apply. Ideally what I would like is to create a libc with functions like acos called something like __xxx_acos that can still be recognized to be optimized. RTLIB is pretty limited but it works fine, I can just use

On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Tim, > > Currently, I have to do multiple things: > > 1) create some setLibcallNames in XXXISelLowering.cpp to generate correct > naming for RTLIBS. > 2) lower ISD down to an RTLIB for some calls (and then do solution 1 on > those to get correct names) These solve a related but different -

If I do T.getArch() == xxx TLI.setUnavailable(LibFunc::copysign) then this works at generating a call instead of not being able to select the ISD::FCOPYSIGN, but I don't know why I don't need to do this for other LibFunc functions (such as floor, etc... these generate call just fine)? Thanks, Ryan On Tue, Jun 14, 2016 at 11:58 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:

Thx for the feedback David. So we're heading toward a broader > __attribute__((disable_call_synthesis)) David what do you think about the additional version that restrict the effect to a few named functions? > e.g. __attribute__((disable_call_synthesis("memset", "memcpy", "sqrt"))) A warning should be issued if the arguments are not part of

In the first code I see a 'tail call @acos', in the second code I see a tail call @llvm.acos.f32'. (sorry, there should be only one input for acos, I've been trying many libm/libc functions). Not sure why it's called TargetLibraryInfo if it's not in target specific code? It seems that ALL targets use this code, making it generic. Am I missing something here? Basically

I'm trying to figure out exactly how the intrinsics/libc/libm work in llvm. For example, this code return user defined function: float acos(float x, float y) { return x+y; } float a; void foo(float b, float c) { a = acos(b, c); } But this code returns llvm.intrinsic: float acos(float, float); float a; void foo(float b, float c) { a = acos(b, c); } float acos(float x, float y) {

*TL;DR:* Defining memory functions in C / C++ results in a chicken and egg problem. Clang can mutate the code into semantically equivalent calls to libc. None of `-fno-builtin-memcpy`, `-ffreestanding` nor `-nostdlib` provide a satisfactory answer to the problem. *Goal* Create libc's memory functions (aka `memcpy`, `memset`, `memcmp`, ...) in C++ to benefit from compiler's knowledge and

On Tue, Jun 25, 2019 at 2:53 AM Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 24 Jun 2019 at 23:23, Siva Chandra via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hello LLVM Developers, > > > > > > Within Google, we have a growing range of needs that existing libc implementations don't quite address. This is pushing us to

On Fri, Oct 27, 2017 at 1:50 AM, David Chisnall via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This seems slightly inverted. As I understand it, the root of the problem > is that some standards, such as C, C++, and POSIX, define some functions as > special and we rely on their specialness when optimising. Unfortunately, > the specialness is a property of the source

I’m not totally sold on the idea of having it be a layer between system libc and application. I think this is likely to create a split between windows and non windows that will be difficult to overcome. It also seems like it brings with it its own set of difficulties. Where can you make a separation in libc such that you’re guaranteed that the two pieces do not share any state, especially given

[+CC Kai Nacke, who I remember talking about this topic at a FOSDEM 2014 talk] On 2019-01-15 19:14, Reid Kleckner via llvm-dev wrote: > On Tue, Jan 15, 2019 at 9:24 AM David Greene via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> writes: >> >> > I'm not opposed to this in principle,

Hi All, TLDR: Allow calling conventions to be defined on-the-fly for functions in LLVM-IR, comments are requested on the mechanism and syntax. Summary ======= This is a proposal for adding a mechanism by which LLVM can be used to generate code fragments adhering to an arbitrary calling convention. Intended use cases are: generating code intended to be called from the shadow of a stackmap or

On Jan 16, 2019, at 1:33 AM, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 15/01/2019 21:56, Manuel Jacob via llvm-dev wrote: >> Sometimes people complain that ABI handling in the frontend is hard and that they have to duplicate (in their language’s frontend) what Clang does. However, I don’t think that pushing more of this complexity into LLVM would be a

On 29 March 2017 at 02:33, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > sin/cos are libm functions, and so a libcall to those need to honour the > floating point ABI requests. The calling convention to be followed there > should match `-mfloat-abi` (that is, -mfloat-abi=hard => AAPCS/VFP, > -mfloat-abi=soft => AAPCS). Exactly, but they're not, and that's

David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> writes: > I'm not opposed to this in principle, and actually I'd quite like to > move in this direction and remove our reliance on undocumented and > inconsistent conventions between the back end and the front end for > conveying information about ABIs. For example, returning two 32-bit > integers or a pair of

2017-10-27 20:31 GMT+02:00 Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org>: > I agree. Marking external functions from system headers seems like a > reasonable heuristic. We'd need some heuristic because it's not reasonable > for the frontend to know about every function the optimizer knows about. > Over-marking seems okay, however. Sorry for the naive question, why

On 2 March 2016 at 19:01, John McCall <rjmccall at apple.com> wrote: > Also, just a quick question. I’m happy to continue to talk about the actual > design and implementation of LLVM IR on this point, and I’d be happy to > put out the actual patch we’re initially proposing. Obviously, all of this code > needs to go through the normal LLVM/Clang code review processes. But >

At least for Linux/Unix, there's very little you can actually achieve without at least some of the libc linked into your own system. Unless you actually write your own system call interface functions - which is dependent on the processor architecture (using `int X` [or `syscall`] in x86, perhaps `trap Y` in 68K, `swi` on ARM, etc) - values for X may vary depending on OS too, and ABI (different

I updated one of my powerpc64le llvm test systems to Fedora 25 and I started getting a whole bunch of sanitizer test case failures. I tried testing some earlier revisions on the new OS that had worked fine under the old but they generate the same errors now so it isn't any changes in llvm. There are two different errors: FATAL: ThreadSanitizer: unsupported VMA range FATAL: Found 47 -

I've gotten a fantastic bug report. Consider the LLVM IR: target triple = "x86_64-unknown-linux-gnu" define internal i8* @access({ i8* }* %arg, i64) { ret i8* undef } define i8* @g({ i8* }* %arg) { bb: %tmp = alloca { i8* }*, align 8 store { i8* }* %arg, { i8* }** %tmp, align 8 br i1 undef, label %bb4, label %bb1 bb1: %tmp2 = load { i8* }*, { i8* }** %tmp, align 8