fast-isel should support vector stores

[Quuxplusone]

Bugzilla Link	PR10550
Status	RESOLVED FIXED
Importance	P normal
Reported by	Matt Pharr (matt@pharr.org)
Reported on	2011-08-01 10:32:41 -0700
Last modified on	2015-10-15 23:25:03 -0700
Version	trunk
Hardware	PC All
CC	dpatel@apple.com, echristo@gmail.com, llvm-bugs@lists.llvm.org, richard@xmos.com
Fixed by commit(s)
Attachments	debug.ll.gz (66731 bytes, application/x-gzip)
Blocks
Blocked by
See also

Created attachment 6984
test case

I'm seeing some undesirable behavior where, when generating debugging
information, sometimes the point in the debugger will jump forwards and
backwards during single stepping, even though the output from our frontend
(this is the ispc compiler), is emitting LLVM instructions with a strictly
forward-moving/increasing set of source locations.  I'm wondering if we're
doing something wrong here, or if this points to a bug somewhere in LLVM.

I've attached a case that demonstrates this.  Specifically, the instructions in
the LLVM assembly language for the foo() function have the following metadata
items associated with them, in the following order: 5519, 5520, 5522, 5523,
5524, 5525, 5526, 5527, 5528, 5529, 5530, 5531, 5532, 5533, 5534, 5521.  These
correspond to the source file locations: [4,22], [5,5], [5,11], [5,22], [5,23],
[6,14], [6,22], [6,24], [6,26], [8,11], [8,15], [9,9], [9,10], [9,11], [10,12],
[10,12].  ([line, column]).

However, if I run "llc -O0 debug.ll -o debug.s" with top of tree, the set of
source locations indicated in comments jumps from [5,23] to [9,10], and then
back to [6,22].  (And if I single-step through this code in gdb, I see the
corresponding jump around.)

If I dump out the IR after the various passes, it looks like things are still
properly ordered after machine function analysis, but then in the output from
the next pass, X86 DAG->DAG instruction selection, things have gotten out of
order.

[Quuxplusone]

Attached debug.ll.gz (66731 bytes, application/x-gzip): test case

[Quuxplusone]

I don't think this is a bug, due to how the DAG instruction selection works. If
we could get fast-isel working on your source it would jump around much less
(hopefully none at all).

Looks like this mostly has to do with vector math inside of fast-isel:

[yendi:~/tmp] echristo% /Volumes/Data/builds/build-llvm/Debug+Asserts/bin/llc -
fast-isel-verbose debug.ll -O0
FastISel miss:   store <4 x i32> %new_mask, <4 x i32>* %mask_memory, align 1,
!dbg !5479

[Quuxplusone]

I think that fast-isel can select this now given the presence of test cases like fast-isel-vecload.ll.

Feel free to reopen if you find fast-isel isn't working for you.