digitalmars.D.bugs - [Issue 7413] New: Vector literals don't work
- d-bugmail puremagic.com (23/23) Jan 31 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (17/17) Jan 31 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (7/7) Mar 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (15/15) Mar 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (8/8) Mar 11 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (14/14) Mar 11 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (10/10) Apr 21 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (13/18) May 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (7/7) May 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (7/9) May 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (8/8) May 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (11/11) May 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (11/12) May 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (13/22) May 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (8/22) May 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (13/31) May 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
- d-bugmail puremagic.com (14/42) May 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7413
http://d.puremagic.com/issues/show_bug.cgi?id=7413
Summary: Vector literals don't work
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody puremagic.com
ReportedBy: turkeyman gmail.com
Vector literals in the form:
float4 v = [1,2,3,4];
still don't appear to work...
Literal should be allocated & aligned, ideally PC relative, right next to the
function (at least possible in x64).
Additionally, assigning literals '0' or [0,0,0,0] should generate the
appropriate xor opcode.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
d-bugmail puremagic.com http://d.puremagic.com/issues/show_bug.cgi?id=7413 There's a bunch of other handy immediates too: -1 = cmpeq(anyReg, anyReg) - 1 opcode, always better than a load 1,3,7,15,etc can be generated by shifting -1 right by some immediate - 2 opcodes, pc-relative load might be better, depends on pipeline 2,4,8,16,etc can be generated by shifting 1 left - 3 opcodes, pc-relative load is probably better, depends on pipeline 1.0f (0x3f800000) can be generated by shifting -1 right 25 bits, then left 23 bits - 3 opcodes, pc-relative load is probably better, depends on pipeline etc... Just something to be aware of -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 31 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413 I'd like to see this promoted above the priority of other SIMD tasks. This is holding me up. I can't write unit tests without literals. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413
Sean Cavanaugh <WorksOnMyMachine gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |WorksOnMyMachine gmail.com
14:16:27 PST ---
Hex float constants don't seem to be expressive enough to handle all 2^32 or
2^64 bit patterns for float or double (nan, exponent masks, mantissa only masks
etc).
This is a problem for defining more exotic data while maintining the correct
'type' for the constant (float4 instead of an int4, double2 instead of long2
etc)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413
Manu <turkeyman gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |blocker
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 11 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413 Walter had planned to use standard array literal syntax as far as I knew: float4 v = [1.0, 2.0, 3.0, 4.0]; shourt8 sv = [1,2,3,4,5,6,7,8]; How he intended to disambiguate the type, I have no idea. Vector literals must be 128bit aligned, so the compiler needs to recognise they're being assigned to a vector and treat them special. It sounds better to have an explicit literal syntax to me. I guess there's always this option, but it's horrible: int4 v = __vector([1,2,3,4]); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 11 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413
SomeDude <lovelydear mailmetrash.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lovelydear mailmetrash.com
PDT ---
See also issue 7414
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 21 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413
Note that for the moment you can do things like:
int[4] o = [1,2,3,4];
int4 v1;
v1.array = o;
Indeed, but that's not something you can just type conveniently in user code.
I wrap that in a little constructor function, which is fine for now.
Proper literals are blocking std.simd though (which I'd really like to finish).
I don't think it's fair to say it's done without literals, and unit tests which
need an awful lot of literals.
If it's not likely to make the short list though, I'll finish it off with some
sort of constructor function in the mean time.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413 10:40:39 PDT --- I'm looking in to it, I just thought that the workaround could keep you going for the moment. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413I'm looking in to it, I just thought that the workaround could keep you going for the moment.Yeah, no worries. Already on it. Cheers :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413 Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b4ab1b0982a68284dcb8780e7d1e5f701aeefaa5 fix Issue 7413 - Vector literals don't work -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 02 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413
Walter Bright <bugzilla digitalmars.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
02:22:42 PDT ---
Haven't done the special case optimizations for constant loading.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 02 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413Haven't done the special case optimizations for constant loading.No problem, I'm using GDC anyway which might detect those in the back end. An efficient implementation would certainly use at least an xor for 0 initialisation, and the other tricks will get different mileage depending on the length of the pipeline surrounding. Not accessing memory is always better if there are pipeline cycles to soak up the latency. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 02 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413
Don <clugdbug yahoo.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |clugdbug yahoo.com.au
Haven't done the special case optimizations for constant loading.
No problem, I'm using GDC anyway which might detect those in the back end.
An efficient implementation would certainly use at least an xor for 0
initialisation, and the other tricks will get different mileage depending on
the length of the pipeline surrounding. Not accessing memory is always better
if there are pipeline cycles to soak up the latency.
The -1 trick is always worth doing, I think. Agner Fog has a nice list in his
optimisation manuals, but the only ones _always_ worth doing are the 0 and -1
integer cases, and the 0.0 floating point case (also using xor).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 02 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413If the compiler knows anything about the pipeline around the code, it should be able to make the best choice about the others. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------The -1 trick is always worth doing, I think. Agner Fog has a nice list in his optimisation manuals, but the only ones _always_ worth doing are the 0 and -1 integer cases, and the 0.0 floating point case (also using xor).Haven't done the special case optimizations for constant loading.No problem, I'm using GDC anyway which might detect those in the back end. An efficient implementation would certainly use at least an xor for 0 initialisation, and the other tricks will get different mileage depending on the length of the pipeline surrounding. Not accessing memory is always better if there are pipeline cycles to soak up the latency.
May 02 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413My guess is that it's pretty rare that the alternative sequences are favoured just on the basis of the pipeline, since MOVDQA only uses a load port, and nothing else. Especially on Sandy Bridge or AMD, where there are two load ports. So I doubt there's much benefit to be had. By contrast, if there's _any_ chance of a cache miss, they'd be a huge win, but unfortunately that's far beyond the compiler's capabilities. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------If the compiler knows anything about the pipeline around the code, it should be able to make the best choice about the others.The -1 trick is always worth doing, I think. Agner Fog has a nice list in his optimisation manuals, but the only ones _always_ worth doing are the 0 and -1 integer cases, and the 0.0 floating point case (also using xor).Haven't done the special case optimizations for constant loading.No problem, I'm using GDC anyway which might detect those in the back end. An efficient implementation would certainly use at least an xor for 0 initialisation, and the other tricks will get different mileage depending on the length of the pipeline surrounding. Not accessing memory is always better if there are pipeline cycles to soak up the latency.
May 02 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7413And that's precisely my reasoning. If the compiler knows the state of the pipeline around the load, and there aren't conflicts, ie, can slip the instructions in for free between other pipeline stalls, then generating an immediate is always better than touching memory. Schedulers usually do have this information while performing code generation, so it may be possible. These sorts of considerations are obviously much more critical for non-x86 based architectures though, as with basically all optimisations ;) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------My guess is that it's pretty rare that the alternative sequences are favoured just on the basis of the pipeline, since MOVDQA only uses a load port, and nothing else. Especially on Sandy Bridge or AMD, where there are two load ports. So I doubt there's much benefit to be had. By contrast, if there's _any_ chance of a cache miss, they'd be a huge win, but unfortunately that's far beyond the compiler's capabilities.If the compiler knows anything about the pipeline around the code, it should be able to make the best choice about the others.The -1 trick is always worth doing, I think. Agner Fog has a nice list in his optimisation manuals, but the only ones _always_ worth doing are the 0 and -1 integer cases, and the 0.0 floating point case (also using xor).Haven't done the special case optimizations for constant loading.No problem, I'm using GDC anyway which might detect those in the back end. An efficient implementation would certainly use at least an xor for 0 initialisation, and the other tricks will get different mileage depending on the length of the pipeline surrounding. Not accessing memory is always better if there are pipeline cycles to soak up the latency.
May 03 2012