May 29 2019
May 28 2019
May 20 2019
May 15 2019
May 9 2019
@craig.topper Yes, X86GenDAGIsel.inc generates the same before/after this change.
May 8 2019
Apr 15 2019
Mar 20 2019
Mar 18 2019
Thanks again Denis, this looks good to me. Shall I commit this piece as well?
Mar 14 2019
Mar 13 2019
Mar 12 2019
Yes Denis, I will try to push this for you tomorrow. Thanks!
Mar 7 2019
Yes, this looks fine with me too Denis. As a process matter, perhaps it makes sense to split into 2 pieces: "Just add the instruction encodings + disasm tests", and then "add the pass to generate pre-/post-increment instructions + tests"
Both pieces look fine with me.
Mar 5 2019
Can you add a few disassembler tests for the new variants here?
Sep 6 2018
Great, thanks for doing this!
Thanks, can you add a test to make sure the disassembler doesn't crash in this case?
Apr 13 2018
Yes, this looks good to me.
Apr 6 2018
Committed in r329404.
Apr 5 2018
Apr 4 2018
Do you need me to commit this for you?
Apr 2 2018
Feb 14 2018
Feb 9 2018
Feb 8 2018
Jan 17 2018
Nov 28 2017
Nov 27 2017
OK, I was aware of these...but didn't know that you'd need them for the debugger. There are a couple of others (mayLoad, mayStore, Defs STATUS32), but I was going to add them when the code generation uses them. Thanks!
Nov 15 2017
@kparzysz, procedural question...am I OK to commit this for Tatyana, or do we need someone else to also sign off on this as well?
Nov 13 2017
Nov 8 2017
I don't personally feel strongly about either of these.
I'm generally trying to match the style in other backends, which on observation I thinke would either just implement the logic inline, or create a new static routine...and omit auto.
I was wrong on other details myself originally.
But, I'm also a newbie at this reviewing bit (like I somehow mistakenly marked this as accepted?), so I'm happy to be told otherwise.
Oct 12 2017
I'm getting a few errors when running these tests now?
Sep 20 2017
Sep 19 2017
Sep 18 2017
Sep 1 2017
Aug 31 2017
Aug 24 2017
Aug 23 2017
Thanks for the help/comments everyone. Is this all OK to submit?
- Remove copyright notices
- Add myself as the ARC backend owner in CODE_OWNERS.txt
Aug 22 2017
Any comments or suggestions about Krzysztof's copyright notice question here? Are they OK in, or should the notices be taken out?
Aug 18 2017
Aug 17 2017
Aug 16 2017
Aug 9 2017
Aug 8 2017
Hello Eugene, Matt,
Thanks again for taking a look. This should address all of the comments so far.
- Change line-1 comments to be 80-characters, and unify format.
- Add appropriate spacing around namespaces, and add '// end namespace XYZ' comments.
- Fix some other spacing issues, and remove some empty comment lines.
- Remove a couple of useless .str() calls.
- Implement TII getInstSizeInBytes method. Use this method in ARCBranchFinalize pass.
- Change Expand Pseudos to delete Instructions as encountered, rather than collect and delete at end.
- Remove all target-specific Load/Store lowering: The target independent path works fine for what we have.
- Add tests for unaligned load/store.
- Remove noisy DEBUG output from ARCISelLowering.
- Use getStoreSize where appropriate in ARCISelLowering.
- Run missed clang-tidy checks from last time (fixes ARCTargetLowering::isLegalAddressingMode, static isBRccPseudo in ARCBranchFinalize).
Aug 7 2017
Aug 4 2017
Thanks for the comments and suggestions. I think I've addressed you're comments, let me know if you find things I missed.
- Run clang-tidy modernize, and fix resulting issues.
- Add ending "#endif // THIS_FILE" to a number of files.
- Remove a few needless extra lines, and a couple of required separating lines.
- Change a couple typedef -> using.