search for: convent

Hi, This is the first time I've posted, and I apologize if I formulate this incorrectly. I am analyzing data from a multi-region carrot variety trial. 35 varieties of carrots were grown in 3 randomized complete blocks in organic and conventional fields in Wisconsin, Indiana, Washington, and California. In this example I am comparing the heights of the carrot tops at harvest. In other words, I have 3 fixed effects: Region, System, VarName, one random effect: Rep, and one response variable: TopHeightHarvestAve. Some plots are missing...

From: Justin Holewinski [mailto:justin.holewinski at gmail.com] Sent: Tuesday, December 13, 2011 10:50 AM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Changes to the PTX calling conventions On Tue, Dec 13, 2011 at 12:54 PM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote: From: Justin Holewinski [mailto:justin.holewinski at gmail.com<mailto:justin.holewinski at gmail.com>] Sent: Tuesday, December 13, 2011 9:48 AM To: Villmow, M...

A concrete example: We''re building a system to organize the information about workshops being held in various conventions. A convention has more than one workshop, and each workshop can be held in more than one convention. Also each workshop has a host, who is specific to a workshop being held in a specific convention. For example, Matz may host an "Introduction to Ruby" workshop in RubyConf. And _why m...

...icah.Villmow at amd.com>wrote: > ** ** > > *From:* Justin Holewinski [mailto:justin.holewinski at gmail.com] > *Sent:* Tuesday, December 13, 2011 10:50 AM > > *To:* Villmow, Micah > *Cc:* LLVM Developers Mailing List > *Subject:* Re: [LLVMdev] Changes to the PTX calling conventions**** > > ** ** > > On Tue, Dec 13, 2011 at 12:54 PM, Villmow, Micah <Micah.Villmow at amd.com> > wrote:**** > > **** > > **** > > *From:* Justin Holewinski [mailto:justin.holewinski at gmail.com] > *Sent:* Tuesday, December 13, 2011 9:48 AM > *To:*...

Hi, all. Swift uses a non-standard calling convention on its supported platforms. Implementing this calling convention requires support from LLVM and (to a lesser degree) Clang. If necessary, we’re willing to keep that support in “private” branches of LLVM and Clang, but we feel it would be better to introduce it in trunk, both to (1) minimize th...

From: Justin Holewinski [mailto:justin.holewinski at gmail.com] Sent: Tuesday, December 13, 2011 9:48 AM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Changes to the PTX calling conventions On Tue, Dec 13, 2011 at 11:25 AM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote: Currently, PTX has its own calling conventions where they are split into kernel/device. The AMDIL backend requires very similar calling conventions and I was wonderin...

...ow at amd.com>wrote: > ** ** > > ** ** > > *From:* Justin Holewinski [mailto:justin.holewinski at gmail.com] > *Sent:* Tuesday, December 13, 2011 9:48 AM > *To:* Villmow, Micah > *Cc:* LLVM Developers Mailing List > *Subject:* Re: [LLVMdev] Changes to the PTX calling conventions**** > > ** ** > > On Tue, Dec 13, 2011 at 11:25 AM, Villmow, Micah <Micah.Villmow at amd.com> > wrote:**** > > Currently, PTX has its own calling conventions where they are split into > kernel/device. **** > > The AMDIL backend requires very similar calling c...

Hi llvm-dev, Every now and then, when building a direct ``CallInst`` either from IRBuilder or through ``Create*``, I have a latent bug because the calling convention (CC) expected by the function is not set on the call, and I need to manually call ``setCallingConv``. Now, from LangRef#calling-conventions, The calling convention of any pair of dynamic caller/callee must match, or the behavior of the program is undefined. So the behavior is correctl...

Currently, PTX has its own calling conventions where they are split into kernel/device. The AMDIL backend requires very similar calling conventions and I was wondering if we could change the calling conventions from PTX_* to something more generic? Maybe just Kernel/Device? Or would it be preferable to add a new calling convention that is...

...> > + const Function *F = MF->getFunction(); >> > + ghcCall = (F ? F->getCallingConv() == CallingConv::GHC : false); >> > + } >> >> > This bit looks dubious. Why do you need to do it? >> >> What exactly? We need to test if this is GHC calling convention or not >> and if >> its, then return different set of callee saved regs. What exactly >> don't you like >> on this piece? > > I don't see anyone else rummaging around inside the original function > for the > calling convention, so why do you need to?...

...on(); >>>> > + ghcCall = (F ? F->getCallingConv() == CallingConv::GHC : false); >>>> > + } >>>> >>>> > This bit looks dubious. Why do you need to do it? >>>> >>>> What exactly? We need to test if this is GHC calling convention or not >>>> and if >>>> its, then return different set of callee saved regs. What exactly >>>> don't you like >>>> on this piece? >>> >>> I don't see anyone else rummaging around inside the original function >>> f...

I’d like to discuss revising the LLVM coding conventions to change the naming of variables to start with a lowercase letter. This should not be a discussion on the pain of such a transition, or how to get from here to there, but rather, if there is a better place to be. My arguments for the change are: 1. No other popular C++ coding style uses c...

...on *F = MF->getFunction(); >>> > + ghcCall = (F ? F->getCallingConv() == CallingConv::GHC : false); >>> > + } >>> >>> > This bit looks dubious. Why do you need to do it? >>> >>> What exactly? We need to test if this is GHC calling convention or not >>> and if >>> its, then return different set of callee saved regs. What exactly >>> don't you like >>> on this piece? >> >> I don't see anyone else rummaging around inside the original function >> for the >> calling conv...

...'t matter what OpenCL program you are trying to compile, the address space information for each backend doesn't change. > > So there are multiple ways to do this without requiring a new interface into LLVM and further linking the backends and the frontend. > 1) Utilize the calling convention and standardize the address space mappings for each language. If the address space interpretation is different, a different calling convention is required for that backend. Say you have the OpenCL calling convention, the C calling convention, and the C++AMP calling convention. The backends that...

Hi Let''s say we have model Foo. Each Foo instance can have several bars. Those bars are primitive, so they shouldn''t be models. For example, Foo might be a type of convention, and the bars might be years the convention was held in. Naively, we would have a conventions_years date, and put: has_many :years inside class Convention. But then we''d get an error, since for has_many to work, there must be a Year model. Which is silly: why would we have a Year mode...

On Wed, Oct 8, 2014 at 7:20 PM, Nick Kledzik <kledzik at apple.com> wrote: > Sure, I actually have no problem with this. > > I'm going to point out that one of the naming conventions used by LLD has > serious problems: naming variables with a leading underscore puts them > *way* too close to the reserved identifier space. Folks have accidentally > ended up with reserved names quite a few times already. > > The lld conventions for ivars is a leading underscore...

Hi @ll, I would like to obsolete and completely remove the WebKit Calling Convention. The CC was originally added for FTL and there are no other users I am aware off. Since WebKit moved away from LLVM a while ago I don’t see the need to keep the dead code around anymore. Please let me know if anyone happens to use this calling convention or has any objection with removing it....

On Tue, Dec 13, 2011 at 11:25 AM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > Currently, PTX has its own calling conventions where they are split into > kernel/device. **** > > The AMDIL backend requires very similar calling conventions and I was > wondering if **** > > we could change the calling conventions from PTX_* to something more > generic?**** > > ** ** > > Maybe just Kernel/...

...e as areas of noticeable divergence: - Constructors' initializer lists - Naming patterns (for locals, members, functions, arguments, etc...) My more general desire is for LLD's codebase to strive for consistency with LLVM's and Clang's. This, of course, is a two-way street. Several conventions have started with the Clang codebase and migrated to be more widely used within LLVM. > The LLVM family of projects have a range of coding conventions. libc++, > lldb, and LLVM core have different styles. That is a good thing. Coding > conventions should not be ruled with an iron...

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...