Tue, Dec 1
Mon, Nov 30
Update comments following suggestions.
Thank you for reviewing.
Fri, Nov 27
I understand this is necessary for VE ABI compliance. Is there anything in LLVM that says a truncate has to zero-out all leading bits?
Correct typo in a comment
Thu, Nov 26
Tue, Nov 24
Hi, it works fine for, not merged yet, VE architecture. Thank you for emergency patch.
Mon, Nov 23
Small checks like 80 columns and indentation. And one question about how you plan to implement test cases for fold immediates.
Sun, Nov 22
Fri, Nov 20
I add some comments inlined.
Update regression test and rebase it. Need to inspect behavior of VEISelDAGToDAG.
Rebase and correct capitalization. Also add two regression tests. The
test_frame4294967296 function didn't allocate stack frame correctly before
It's a good question. VE has 32 bits offset, so we don't consider such large frames or data structures seriously.
With the use of CReduce & some manual reduction, I managed to get the test down to this:
Thu, Nov 19
There is no assertions.
'cast' has an assertion built into it if the cast is not valid ( https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Support/Casting.h#L250 ). If this dyn_cast has any effect (ie: if any execution of the program has different behavior with the dyn_cast compared to the cast) it should be true that the cast version of the code would've triggered an assertion on that same program.
Are you building/running the code with assertions enabled? (I'm not asking you to add a new assertion to the code - I'm asking if you have assertions enabled in your build so you'd see an assertion before/rather than a segmentation fault)
Were you testing with assertions enabled? I'd expect a test case to cause an assertion failure (when the "cast" was applied to an object that wasn't the intended type) rather than a segmentation fault.
Hi, @dblaikie. I generated a test case which causes a segmentation fault if we didn't apply D91151 (https://reviews.llvm.org/D91151) following your suggestion. I appreciate if you have more suggestions.
dividing the widest register in bits by the smallest possible type width in bits (1) seems a suitable upper bound to preserve the spirit of the assert
I thought it's a good idea when I hear it from @fhahn, but... I think It's not a good idea since 1) WidestRegister holds bit width, 2) MaxVectorSize is calculated from TTI->getRegisterBitWidth anyway.
Wed, Nov 18
Thank you for updates.
Tue, Nov 17
I think removing this is good idea, but I'm not sure why the maximum vector size was limited to 64 and recently jumped up to 256. So, I cannot say LGTM atm. Does anyone know background on this?
Mon, Nov 16
@dblaikie, Thank you for suggestion. I'll try to make it tonight.
Update by following clang-tidy.