<feed xmlns='http://www.w3.org/2005/Atom'>
<title>bcm5719-llvm/llvm/test/CodeGen/Mips/cconv, branch meklort-10.0.1</title>
<subtitle>Project Ortega BCM5719 LLVM</subtitle>
<id>https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1</id>
<link rel='self' href='https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/'/>
<updated>2019-10-07T14:01:37+00:00</updated>
<entry>
<title>[Mips] Always save RA when disabling frame pointer elimination</title>
<updated>2019-10-07T14:01:37+00:00</updated>
<author>
<name>Simon Atanasyan</name>
<email>simon@atanasyan.com</email>
</author>
<published>2019-10-07T14:01:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=55ac7458280dddf253a235b2180d8053d5b05d0c'/>
<id>urn:sha1:55ac7458280dddf253a235b2180d8053d5b05d0c</id>
<content type='text'>
This ensures that frame-based unwinding will continue to work when
calling a noreturn function; there is not much use having the caller's
frame pointer saved if you don't also have the caller's program counter.

Patch by James Clarke.

Differential Revision: https://reviews.llvm.org/D68542

llvm-svn: 373907
</content>
</entry>
<entry>
<title>[mips][msa] Fix infinite loop for mips.nori.b intrinsic</title>
<updated>2019-09-11T11:16:06+00:00</updated>
<author>
<name>Simon Atanasyan</name>
<email>simon@atanasyan.com</email>
</author>
<published>2019-09-11T11:16:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=d811d9115b0b2d004a568e8ebdb37ba0ea6397d1'/>
<id>urn:sha1:d811d9115b0b2d004a568e8ebdb37ba0ea6397d1</id>
<content type='text'>
When value of immediate in `mips.nori.b` is 255 (which has all ones in
binary form as 8bit integer) DAGCombiner and Legalizer would fall in an
infinite loop. DAGCombiner would try to simplify `or %value, -1` by
turning `%value` into UNDEF. Legalizer will turn it back into `Constant&lt;0&gt;`
which would then be again turned into UNDEF by DAGCombiner. To avoid this
loop we make UNDEF legal for MSA int types on Mips.

Patch by Mirko Brkusanin.

Differential Revision: https://reviews.llvm.org/D67280

llvm-svn: 371607
</content>
</entry>
<entry>
<title>[mips] Explicitly select `mips32r2` CPU for test cases require 64-bit FPU. NFC</title>
<updated>2019-07-09T15:48:05+00:00</updated>
<author>
<name>Simon Atanasyan</name>
<email>simon@atanasyan.com</email>
</author>
<published>2019-07-09T15:48:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=623282f0dd7fb1dba7623f2b10294f003f92570e'/>
<id>urn:sha1:623282f0dd7fb1dba7623f2b10294f003f92570e</id>
<content type='text'>
Support for 64-bit coprocessors on a 32-bit architecture
was added in `MIPS32 R2`.

llvm-svn: 365507
</content>
</entry>
<entry>
<title>[mips] Emit .reloc R_{MICRO}MIPS_JALR along with j(al)r(c) $25</title>
<updated>2019-01-17T21:50:37+00:00</updated>
<author>
<name>Vladimir Stefanovic</name>
<email>vladimir.stefanovic@rt-rk.com</email>
</author>
<published>2019-01-17T21:50:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=3daf8bc96a121279030e93f4462ff4daa1ffa8e4'/>
<id>urn:sha1:3daf8bc96a121279030e93f4462ff4daa1ffa8e4</id>
<content type='text'>
The callee address is added as an optional operand (MCSymbol) in
AdjustInstrPostInstrSelection() and then used by asm printer to insert:
'.reloc tmplabel, R_MIPS_JALR, symbol
tmplabel:'.
Controlled with '-mips-jalr-reloc', default is true.

Differential revision: https://reviews.llvm.org/D56694

llvm-svn: 351485
</content>
</entry>
<entry>
<title>[DAGCombiner][X86][Mips] Enable combineShuffleOfScalars to run between vector op legalization and DAG legalization. Fix bad one use check in combineShuffleOfScalars</title>
<updated>2018-11-09T18:04:34+00:00</updated>
<author>
<name>Craig Topper</name>
<email>craig.topper@intel.com</email>
</author>
<published>2018-11-09T18:04:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=9a7e19b8f28eb817d9183d8f921abf5aae31f210'/>
<id>urn:sha1:9a7e19b8f28eb817d9183d8f921abf5aae31f210</id>
<content type='text'>
It's possible for vector op legalization to generate a shuffle. If that happens we should give a chance for DAG combine to combine that with a build_vector input.

I also fixed a bug in combineShuffleOfScalars that was considering the number of uses on a undef input to a shuffle. We don't care how many times undef is used.

Differential Revision: https://reviews.llvm.org/D54283

llvm-svn: 346530
</content>
</entry>
<entry>
<title>[DAGCombiner] Remove reduceBuildVecConvertToConvertBuildVec and rely on the vectorizers instead (PR35732)	</title>
<updated>2018-11-02T11:06:18+00:00</updated>
<author>
<name>Simon Pilgrim</name>
<email>llvm-dev@redking.me.uk</email>
</author>
<published>2018-11-02T11:06:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=cdcbeb4997a85895266b688b6077c48fbe1c4085'/>
<id>urn:sha1:cdcbeb4997a85895266b688b6077c48fbe1c4085</id>
<content type='text'>
	
reduceBuildVecConvertToConvertBuildVec vectorizes int2float in the DAGCombiner, which means that even if the LV/SLP has decided to keep scalar code using the cost models, this will override this.

While there are cases where vectorization is necessary in the DAG (mainly due to legalization artefacts), I don't think this is the case here, we should assume that the vectorizers know what they are doing.

Differential Revision: https://reviews.llvm.org/D53712

llvm-svn: 345964
</content>
</entry>
<entry>
<title>[LegalizeVectorTypes] When widening the result of a bitcast from a scalar type, use a scalar_to_vector to turn the scalar into a vector intead of a build vector full of mostly undefs.</title>
<updated>2018-10-12T21:59:55+00:00</updated>
<author>
<name>Craig Topper</name>
<email>craig.topper@intel.com</email>
</author>
<published>2018-10-12T21:59:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=435e38a5df057385d2e2d6471c330af1bf43306b'/>
<id>urn:sha1:435e38a5df057385d2e2d6471c330af1bf43306b</id>
<content type='text'>
This is more consistent with what we usually do and matches some code X86 custom emits in some cases that I think I can cleanup.

The MIPS test change just looks to be an instruction ordering change.

llvm-svn: 344422
</content>
</entry>
<entry>
<title>[mips] Mark fmaxl as a long double emulation routine</title>
<updated>2018-10-12T08:18:38+00:00</updated>
<author>
<name>Stefan Maksimovic</name>
<email>stefan.maksimovic@mips.com</email>
</author>
<published>2018-10-12T08:18:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=285c0f4fdc14a266f0765816c42c2c8a57601cbb'/>
<id>urn:sha1:285c0f4fdc14a266f0765816c42c2c8a57601cbb</id>
<content type='text'>
Failure was discovered upon running
projects/compiler-rt/test/builtins/Unit/divtc3_test.c
in a stage2 compiler build.

When compiling projects/compiler-rt/lib/builtins/divtc3.c,
a call to fmaxl within the divtc3 implementation had its
return values read from registers $2 and $3 instead of $f0 and $f2.
Include fmaxl in the list of long double emulation routines
to have its return value correctly interpreted as f128.

Almost exact issue here: https://reviews.llvm.org/D17760

Differential Revision: https://reviews.llvm.org/D52649

llvm-svn: 344326
</content>
</entry>
<entry>
<title>[DAG] Fix Big Endian in Load-Store forwarding</title>
<updated>2018-10-11T18:28:59+00:00</updated>
<author>
<name>Nirav Dave</name>
<email>niravd@google.com</email>
</author>
<published>2018-10-11T18:28:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=f1f2a2a31ad6200f468718dbbc75fbfbea152915'/>
<id>urn:sha1:f1f2a2a31ad6200f468718dbbc75fbfbea152915</id>
<content type='text'>
Summary:
Correct offset calculation in load-store forwarding for big-endian
targets.

Reviewers: rnk, RKSimon, waltl

Subscribers: sdardis, nemanjai, hiraditya, jrtc27, atanasyan, jsji, llvm-commits

Differential Revision: https://reviews.llvm.org/D53147

llvm-svn: 344272
</content>
</entry>
<entry>
<title>[DAGCombine] Improve Load-Store Forwarding</title>
<updated>2018-10-10T14:15:52+00:00</updated>
<author>
<name>Nirav Dave</name>
<email>niravd@google.com</email>
</author>
<published>2018-10-10T14:15:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=07acc992dc39edfccc5a4b773c3dcf8a5bf6d893'/>
<id>urn:sha1:07acc992dc39edfccc5a4b773c3dcf8a5bf6d893</id>
<content type='text'>
Summary:
Extend analysis forwarding loads from preceeding stores to work with
extended loads and truncated stores to the same address so long as the
load is fully subsumed by the store.

Hexagon's swp-epilog-phis.ll and swp-memrefs-epilog1.ll test are
deleted as they've no longer seem to be relevant.

Reviewers: RKSimon, rnk, kparzysz, javed.absar

Subscribers: sdardis, nemanjai, hiraditya, atanasyan, llvm-commits

Differential Revision: https://reviews.llvm.org/D49200

llvm-svn: 344142
</content>
</entry>
</feed>
