similar to: [LLVMdev] Heads up, I've backed out significant amounts of the multiple address space conversion changes

I guess I'll try picking this back up. What were the problems exactly from a design perspective? On Nov 1, 2012, at 2:56 , Chandler Carruth <chandlerc at gmail.com> wrote: > TL;DR: See subject. That is all. > ---- > > First off, I want to say I'm sorry for doing this. =/ > > There were several issues that led to this: > > 1) There were several

Outside of what was listed below, which you would have to go back into the other emails/reviews to get into more details, I believe the handling of global constants expressions was problematic with the API's that I had implemented. That said, changes of this magnitude should be done in a branch instead of mainline trunk. Micah -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu

On Thu, Jun 27, 2013 at 12:49 PM, Micah Villmow <micah.villmow at smachines.com > wrote: > That said, changes of this magnitude should be done in a branch instead of > mainline trunk. I strongly disagree. If you think this is the case, we should probably start a new thread (rather than ressurecting this one) with the context of what you want to do and why you think it should be on a

The reason why I say it should be done in a separate branch is that the final design is not necessarily the same as the first initial implementation. There are things that will break and this kind of change touches almost everything, not just the core LLVM libraries. It is hard to get right the first time, and developing it in a sandbox will dramatically decrease the amount of churn that will show

On 27 October 2016 at 19:02, Justin Lebar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, it looks like you're compiling CUDA for an ARM host? This is not > a configuration we have tested, nor is it something we have the > capability of testing at the moment. Hi Justin, NVidia TX1 is the AArch64 Jetson board with proper GPU (we use those). > You may be able to

Is there a way to mark all functions as internal from source via some sort of attribute? Thanks for the tips, Micah From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Tuesday, May 05, 2009 4:16 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Pass to remove unused functions On May 5, 2009, at 4:07 PM, Villmow,

On May 5, 2009, at 4:50 PM, Villmow, Micah wrote: > Is there a way to mark all functions as internal from source via > some sort of attribute? "static". However, if you do that, they won't make it into the bc file. -Chris > > Thanks for the tips, > Micah > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] On Behalf Of

I thought this pass would do it, but when I run it over my bc file the output file is the same as the input file. The issue I guess is a little different. When I link in the huge bc file with the tiny bc file, I only want the resulting bc file to have the function definitions that the tiny bc file requires and not every function in the huge bc file. Any idea's how to do this with the

LLVM seems to be generating way too complex of branching based on the short-circuit optimization. The code in question is as follows: define void @ test_fc_while_and(float %x, float %y, float addrspace(11)* %result) nounwind { entry: %tobool3 = fcmp une float %x, 0.000000e+000 ; <i1> [#uses=1] %tobool24 = fcmp une float %y, 0.000000e+000 ;

Hi James, some additional comments regarding some of your questions: Q: Is SPIR meant to be storage-only, or to allow optimizations to be done? I agree with Micah that optimizing a SPIR module might make it less portable. However, SPIR doesn't prohibit optimizations. It is up to the OpenCL optimizer to decide when to "materialize" SPIR to a device specific LLVM module or even

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of James Molloy > Sent: Tuesday, September 11, 2012 8:49 AM > To: Ouriel, Boaz > Cc: cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] SPIR provisional specifciation is now available > in the Khronos website > > Hi Boaz, >

> NVidia TX1 is the AArch64 Jetson board with proper GPU (we use those). Sure, I believe that others use this configuration. I was saying, "we", being, myself and those whom I work closely with, do not. Sorry if that wasn't precise. It is still not clear to me if the original poster is compiling for ARM or not. But it sounds like you're going to help them get this

Hi James, This is very good feedback. 1. Adding the new calling conventions - It seems like the appropriate thing to do vs. metadata. Some OpenCL backends can choose to implement this calling convention and use it during code generation of OpenCL functions/kernels. Can we agree on this item? 2. Restricting the allowable instructions - As Micah mentioned before, the restrictions are there

Chris, I took a look at AnalyzeBranch and I don't see how it can solve my problem. The issue itself isn't with branching, as I can handle branches fairly well in my custom pass(see the before and after dot files attached). I can take a bunch of branches and construct high level control flow for my backend since I have no ability to do goto/jump, only whileloop and ifs. So analyzing the

Hi Richard, On 7/10/20 11:10 PM, Richard Smith wrote: > Hi Vassil, > > This is a very exciting proposal that I can imagine bringing important > benefits to the existing cling users and also to the clang user and > developer community. Thank you for all the work you and your team have > done on cling so far and for offering to bring that work under the > LLVM umbrella!

On May 5, 2009, at 4:07 PM, Villmow, Micah wrote: > I thought this pass would do it, but when I run it over my bc file > the output file is the same as the input file. that's probably because your symbols are not internal. > > The issue I guess is a little different. When I link in the huge bc > file with the tiny bc file, I only want the resulting bc file to > have

Hi Micah, >> (a) You mention special calling conventions and adding them to LLVM. >> What are their semantics? And what is their purpose? > [Villmow, Micah] One purpose is to differentiate between kernel and device functions. > Another is to differentiate between the standard calling conventions that have > device specific assumptions built into them. Do you have an example

Hi Boaz, Micah, Thanks for the followup. > I agree with Micah that optimizing a SPIR module might make it less portable. > However, SPIR doesn't prohibit optimizations. It is up to the OpenCL optimizer to decide when to "materialize" SPIR to a device specific LLVM module or even convert it to another IR. > It would be useful if we could identify areas in the specification

Hi Boaz, David, Thanks for taking my responses on board. > 1. Adding the new calling conventions - It seems like the appropriate thing to do vs. metadata. Some OpenCL backends can choose to implement this calling convention and use it during code generation of OpenCL functions/kernels. Can we agree on this item? Hmm, this is the one I was most shaky on. I still don't fully understand

> On Apr 22, 2016, at 3:01 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > I feel like this thread got a bit stalled. I'd like to pick it up and try to suggest a path forward. > > I don't hear any real objections to the overall idea of having an LLVM subproject for parallelism runtimes and support libraries. I think we should get that created. I think it