Displaying 20 results from an estimated 80000 matches similar to: "[LLVMdev] RFC: Adding an option to llvm-link to allow it to get a list of input bitcode file names from a file"
2012 Sep 20
2
[LLVMdev] RFC: Adding an option to llvm-link to allow it to get a list of input bitcode file names from a file
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();
2012 Sep 13
0
[LLVMdev] RFC: Adding an option to llvm-link to allow it to get a list of input bitcode file names from a file
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
2012 Sep 21
0
[LLVMdev] RFC: Adding an option to llvm-link to allow it to get a list of input bitcode file names from a file
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
> +++
2012 Sep 21
2
[LLVMdev] RFC: Adding an option to llvm-link to allow it to get a list of input bitcode file names from a file
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]
2012 Sep 13
1
[LLVMdev] RFC: Adding an option to llvm-link to allow it to get a list of input bitcode file names from a file
My assumption is that a user will either specify input file names in the command line or passing them by a list file, but usually would not do both. Making these two different ways of specifying input files mutually exclusive may avoid confusion and misuse.
Sam
From: Villmow, Micah
Sent: Thursday, September 13, 2012 12:54 PM
To: Liu, Yaxun (Sam); llvmdev at cs.uiuc.edu
Subject: RE: [LLVMdev]
2012 Sep 13
0
[LLVMdev] RFC: Adding an option to llvm-link to allow it to get a list of input bitcode file names from a file
Why is there a restriction on the usage between command line and input file? It seems that they both should be able to co-exist and the resulting linking is done as a set of all the bitcode files.
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Liu, Yaxun (Sam)
Sent: Thursday, September 13, 2012 9:51 AM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] RFC:
2012 Oct 04
0
[LLVMdev] RFC: Adding an option to llvm-link to allow it to get a list of input bitcode file names from a file
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
2012 Oct 02
3
[LLVMdev] [llvm-commits] patch to enable response file support in ParseCommandLineOptions
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 file support. The patch also contains a simple test. I did regression check and there are no regressions.
+ llvmdev
Sam
From: Chris Lattner [mailto:clattner at apple.com]
Sent: Sunday, September 30, 2012 2:20 PM
To:
2012 Oct 04
1
[LLVMdev] RFC: Adding an option to llvm-link to allow it to get a list of input bitcode file names from a file
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
2012 Oct 02
1
[LLVMdev] [llvm-commits] patch to enable response file support in ParseCommandLineOptions
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
>
2012 Oct 03
0
[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)
2015 May 17
6
[LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter
> On May 16, 2015, at 12:21 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote:
>
> I am thinking maybe the functionality of the bi-way conversion can be kept at llvm/lib/Bitcode/SPIRV, which will facilitate OpenCL vendors to do conversions between LLVM and SPIR-V. On the other hand, we create a llvm/Target/SPIR-V, which uses llvm/lib/Bitcode/SPIRV to generate SPIR-V. The SPIR-V
2015 May 16
3
[LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter
2015-05-16 6:42 GMT+01:00 Chris Lattner <clattner at apple.com>:
>
> > On May 15, 2015, at 9:53 AM, Chris Bieneman <beanz at apple.com> wrote:
> >
> > +1 to lib/Target/SPIRV/(Reader|Writer)
> >
> > I really like this idea. I’ve talked with some people on both the LLVM and Khronos sides and I really think adding SPIR-V support to LLVM as an optional
2015 May 13
2
[LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter
On Wed, May 13, 2015 at 6:11 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> wrote:
> On 13 May 2015, at 13:56, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote:
> >
> > Khronos Group SPIR WG is working on a bi-way converter between LLVM
> bitcode and SPIR-V (
> https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf ) binary and
> is willing to upstream
2015 May 13
5
[LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter
Khronos Group SPIR WG is working on a bi-way converter between LLVM bitcode and SPIR-V (https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf ) binary and is willing to upstream it to the LLVM project.
The bi-way converter uses a common in-memory representation of SPIR-V. It works by breaking down a module to instructions and construct the translated module in memory then output it.
2016 Sep 18
2
builtins name mangling in SPIR 2.0
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
2016 Sep 16
2
builtins name mangling in SPIR 2.0
+ 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:
2016 May 10
3
[OpenCL] Question about pre-linking passes required to build OpenCL program
+ 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
2015 Jun 18
2
[LLVMdev] [RFC] Proposal for Adding SPIRV Target
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
2015 Jul 07
2
[LLVMdev] [RFC] Proposal for Adding SPIRV Target
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