similar to: [LLVMdev] [llvm-commits] patch to enable response file support in ParseCommandLineOptions

Response file is the conventional name for files serving this purpose. A google search shows the usage of "response file" is not rare. Also it has been used in the LLVM documentation: http://llvm.org/docs/CommandLine.html#response-files Sam -----Original Message----- From: Matt Beaumont-Gay [mailto:matthewbg at google.com] Sent: Tuesday, October 02, 2012 1:35 PM To: Liu, Yaxun (Sam)

Can we call this a "parameters file"? I find "response file" to be non-obvious. On Tue, Oct 2, 2012 at 8:18 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > Thanks Chris for the comment. > > > > Since there is no objection, I attached a new patch which enables response > file support and removes the argument for controlling/disabling response >

Could we enable ReadResponseFiles=true by default? 2012/9/21 Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>: > Well, although cl::ParseCommandLineOptions contains support for @file. By default it is disabled, which is the case for llvm-link. > > To enable @file support in llvm-link, a small change is needed: > > --- llvm-link.cpp.orig 2012-09-20 16:10:50.000000000 -0400 > +++

Well, although cl::ParseCommandLineOptions contains support for @file. By default it is disabled, which is the case for llvm-link. To enable @file support in llvm-link, a small change is needed: --- llvm-link.cpp.orig 2012-09-20 16:10:50.000000000 -0400 +++ llvm-link.cpp 2012-09-20 16:11:24.000000000 -0400 @@ -83,7 +83,7 @@ LLVMContext &Context = getGlobalContext();

I have no objection to that. Actually I am curious why it is disabled by default. If we enable ReadResponseFiles=true by default, we will automatically get support of response file (@file) in all llvm tools. The only issue I can think of is that some users may have file names starting with "@". Sam -----Original Message----- From: NAKAMURA Takumi [mailto:geek4civic at gmail.com]

Liu, Yaxun (Sam) wrote: > I am proposing to add an option to llvm-link allow it to get a list of > input bitcode file names from a file. > > The reason is that there is a limitation for command line length which > limits the number of input bitcode files that can be passed to > llvm-link. By adding this option we can bypass such limitation. > > The name of the option can be

I am proposing to add an option to llvm-link allow it to get a list of input bitcode file names from a file. The reason is that there is a limitation for command line length which limits the number of input bitcode files that can be passed to llvm-link. By adding this option we can bypass such limitation. The name of the option can be discussed. My initial proposal would be -input-file-list.

I don't see any problem mangling it to be honest even though there seems to be only one prototype anyways. We could add restrict in as well. Cheers, Anastasia ________________________________ From: Hongbin Zheng <etherzhhb at gmail.com> Sent: 17 September 2016 05:32:54 To: Liu, Yaxun (Sam) Cc: cfe-dev at lists.llvm.org; llvm-dev; Bader, Alexey (alexey.bader at intel.com); Anastasia

Hi, I am sending a patch to enable response file support in ParseCommandLineOptions. With this change, all llvm tools will support response file. This helps overcome the command line length limit which we encountered recently. Index: include/llvm/Support/CommandLine.h =================================================================== --- include/llvm/Support/CommandLine.h (revision 164408) +++

+ Alexey Anastasia According to SPIR spec v1.2 s2.10.3 2.10.3 The printf function The printf function is supported, and is mangled according to its prototype as follows: int printf(constant char * restrict fmt, ... ) Note that the ellipsis formal argument (...) is mangled to argument type specifier z It seems printf should be mangled. Alexey/Anastasia, What do you think? Thanks. Sam From:

Hi Sam, please add a testcase. Does this cause any regressions? Ciao, Duncan. > I am sending a patch to enable response file support in ParseCommandLineOptions. > With this change, all llvm tools will support response file. This helps overcome > the command line length limit which we encountered recently. > > Index: include/llvm/Support/CommandLine.h > >

So we have been in discussions within the Khronos SPIR-V work group on our push to get our SPIR-V code into tip LLVM and have drawn the following conclusions; * We absolutely must create a fully fledged backend that uses all the machinery that target backends are expected to use. * We probably have to split out the SPIR-V -> LLVM IR into a separate project from LLVM ala Clang et

Hey Tom, Really it was at the behest of the replies - we got a lot of feedback from the mailing list that indicated we'd be putting extra workload of people changing features of the IR if we didn't follow the same mechanisms of the other backends (mostly led by Chandler's very astute comments on the subject). Cheers, -Neil. On 07/07/15 14:43, Tom Stellard wrote: > On Tue, Jul

On Thu, Jun 18, 2015 at 10:26 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Jun 18, 2015, at 9:31 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > > > *From:* Mehdi Amini [mailto:mehdi.amini at apple.com <mehdi.amini at apple.com>] > > *Sent:* Thursday, June 18, 2015 11:24 AM > *To:* Liu, Yaxun (Sam) > *Cc:* llvmdev at cs.uiuc.edu

Thanks a lot. On Mon, Sep 12, 2016 at 1:42 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > If you use the default header file under clang/lib/Headers/opencl-c.h, > get_global_id will be mangled. > > > > If you want to declare get_global_id in your own header, add > __attribute__((overloadable)), then it will be mangled. > > > > Sam > > > >

From: Mehdi Amini [mailto:mehdi.amini at apple.com] Sent: Thursday, June 18, 2015 11:24 AM To: Liu, Yaxun (Sam) Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target On Jun 18, 2015, at 6:23 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>> wrote: Hi Mehdi, Thank you for your comments. My comments are below. Sam From:

+ llvm-dev From: Sumner, Brian Sent: Tuesday, May 10, 2016 3:11 PM To: Anastasia Stulova <Anastasia.Stulova at arm.com>; Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>; cfe-dev (cfe-dev at lists.llvm.org) <cfe-dev at lists.llvm.org>; Pan, Xiuli <xiuli.pan at intel.com>; Bader, Alexey (alexey.bader at intel.com) <alexey.bader at intel.com> Cc: Stellard, Thomas

On 21 September 2012 10:44, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > I have no objection to that. Actually I am curious why it is disabled by default. > > If we enable ReadResponseFiles=true by default, we will automatically get support of response file (@file) in all llvm tools. The only issue I can think of is that some users may have file names starting with

I do not have write access. Please commit the patch for me. Thanks. Sam -----Original Message----- From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] Sent: Thursday, October 04, 2012 10:38 AM To: Liu, Yaxun (Sam) Cc: NAKAMURA Takumi; Nick Lewycky; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] RFC: Adding an option to llvm-link to allow it to get a list of input bitcode file names

Hal, Thanks for your suggestion. I think that makes sense. Currently, non-zero alloca address space is already represented by data layout, e.g., the last component of the data layout of amdgcn---amdgiz target is -A5, which means alloca is in address space 5. How about adding a letter z to -A5 to indicate alloca may have zero value? i.e. -A5 means alloca is in address space 5 and always has