search for: fcas

...cribing the problem? I don't really know otherwise. >> - Once we add vector, should we consider adding other composite types >> in general, including structs? C++ allows this, but has substantial issues >> w.r.t. padding. >> >> I'd say possibly, but FCAs are poorly supported in the IR in general. I >> am not willing to block changes for vectors on changes for FCAs. This has >> never been our policy in the past and should not become so now. >> > > Oh yeah I don't think we should block it. FWIW I expect that some of thes...

> > >>> - Once we add vector, should we consider adding other composite >>> types in general, including structs? C++ allows this, but has substantial >>> issues w.r.t. padding. >>> >>> I'd say possibly, but FCAs are poorly supported in the IR in general. I >>> am not willing to block changes for vectors on changes for FCAs. This has >>> never been our policy in the past and should not become so now. >>> >> >> Oh yeah I don't think we should block it. FWIW I expe...

...assumptions in the last > two paragraphs may not be valid. > Indeed! > - Once we add vector, should we consider adding other composite types > in general, including structs? C++ allows this, but has substantial issues > w.r.t. padding. > > I'd say possibly, but FCAs are poorly supported in the IR in general. I > am not willing to block changes for vectors on changes for FCAs. This has > never been our policy in the past and should not become so now. > Oh yeah I don't think we should block it. FWIW I expect that some of these will generate calls...

...is closer to the target where the 'no bits change' statement ceases to be true in some cases. > A couple of points that will need clarified: > - Does this only apply to vector types? It definitely doesn't apply between pointer types today. What about integer, floating point, and FCAs? I've only seen it for vector types so far but in theory it could happen for other types. I'd expect FCAs to encounter it since the physical registers may contain padding that isn't present in the LLVM-IR representation and the placement and amount of padding will depend on the exact F...

...ange' statement ceases > to be true in some cases. > > > A couple of points that will need clarified: > > - Does this only apply to vector types? It definitely doesn't > apply between pointer types today. What about integer, floating > point, and FCAs? > > I've only seen it for vector types so far but in theory it could > happen for other types. I'd expect FCAs to encounter it since the > physical registers may contain padding that isn't present in the > LLVM-IR representation and the placement and amou...

On Mon, Dec 14, 2015 at 11:46 AM, Philip Reames <listmail at philipreames.com> wrote: > > > On 12/12/2015 01:44 PM, JF Bastien wrote: > > On Sat, Dec 12, 2015 at 1:24 AM, Philip Reames <listmail at philipreames.com> > wrote: > >> Patch posted for review: http://reviews.llvm.org/D15471 > > > Looking at the patch, I think we should do FP only for now

...n > > some cases. > > > > > > > > > A couple of points that will need clarified: > > > - Does this only apply to vector types? It definitely doesn't apply > > > between pointer types today. What about integer, floating point, > > > and FCAs? > > > > > > > > > > > > I've only seen it for vector types so far but in theory it could > > happen for other types. I'd expect FCAs to encounter it since the > > physical registers may contain padding that isn't present in the > >...

> (Right?) Uh no, the register content explicitly does change :( We insert REV instructions (byteswap) on each bitcast. Bitcasts can be merged and elided etc, but conceptually there's a register content change on every bitcast. James On Wed, 13 Jan 2016 at 18:09 Philip Reames <listmail at philipreames.com> wrote: > > > On 01/13/2016 08:01 AM, Hal Finkel via llvm-dev

Philip Reames wrote: >> 1. Introduce aAny. > > Having a generic any type seems fine. I assume you'd create something like > an llvm_any_type in Intrinsics.td? That's precisely what ifavpAny is about: integer, float, array, vector, pointer Any. aAny is meant for array-Any, and I wonder why so few people care about arrays. I'll go ahead with Any and llvm_any_type.

Hello, In my LLVM frontend (CLR/MSIL), I am currently using first-class aggregates to represent loaded value types on the "CLR stack". However, I noticed that when calling external method taking those aggregate by value, they were not passed as I expected: %COLORREF = type { i8, i8, i8, i8 } declare i32 @SetLayeredWindowAttributes(i8*, %COLORREF, i8, i32) I call this function with

Hi Dan, Thanks a lot for the feedback and apologies for the delay! >> br poison -> UB > What impact does this have on API contracts? Some library functions might currently tolerate being passed an uninitialized value (at the LLVM level; C's semantics are different). However, with the new poison, if the implementation of a function happens to do a branch on the input, the code has

I understand these objections. They ends up being a problem at the limit (ie the example of the 64k store or 1Mb+ aggregate). These probably require their own fix or probably just shouldn't be supported. That being said, there is a vast space between what is done now and aggregate so big that it causes real hard problems like the ones you mention. reducing that gap seems like a win to me.

2015-08-16 23:21 GMT-07:00 David Majnemer <david.majnemer at gmail.com>: > > > Because a solution which doesn't generalize is not a very powerful > solution. What happens when somebody says that they want to use atomics + > large aggregate loads and stores? Give them yet another, different answer? > That would mean our earlier, less general answer, approach was either

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.