Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-06-10T09:34:30+00:00 2020-06-10T09:34:30+00:00 Nathan Ridge zeratul976@hotmail.com 2020-04-01T05:29:58+00:00 urn:sha1:cbc9b92df4582617314b08d1ecef41d355733874 Summary: Fixes https://github.com/clangd/clangd/issues/309 Subscribers: ilya-biryukov, kadircet, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77194 (cherry picked from commit 8b3b7556e9ab6084e9fd337d64dac1c165867d32) 2020-01-14T16:21:42+00:00 Jinsong Ji jji@us.ibm.com 2020-01-14T16:21:13+00:00 urn:sha1:e2b8e2113a4929027a237b67f7be86db4ec103d3 -Werror clang build is broken now. tools/clang/lib/Sema/OpenCLBuiltins.inc:11824:5: error: default label in switch which covers all enumeration values [-Werror,-Wcovered-switch-default] default: We don't need default now, since all enumeration values are covered. Reviewed By: svenvh Differential Revision: https://reviews.llvm.org/D72707 2020-01-08T14:42:24+00:00 Simon Tatham simon.tatham@arm.com 2020-01-08T13:36:25+00:00 urn:sha1:3100480925df10960c1e0a077dd9875037d3fe29 This batch of intrinsics covers two sets of immediate shift instructions, which have in common that they only overwrite part of their output register and so they need an extra input giving its previous value. The VSLI and VSRI instructions shift each lane of the input vector left or right just as if they were normal immediate VSHL/VSHR, but then they only overwrite the output bits that correspond to actual shifted bits of the input. So VSLI will leave the low n bits of each output lane unchanged, and VSRI the same with the top n bits. The V[Q][R]SHR[U]N family are all narrowing shifts: they take an input vector of 2n-bit integers, shift each lane right by a constant, and then narrowing the shifted result to only n bits. So they only overwrite half of the n-bit lanes in the output register, and the B/T suffix indicates whether it's the bottom or top half of each 2n-bit lane. I've implemented the whole of the latter family using a single IR intrinsic `vshrn`, which takes a lot of i32 parameters indicating which instruction it expands to (by specifying signedness of the input and output types, whether it saturates and/or rounds, etc). Reviewers: dmgreen, MarkMurrayARM, miyuki, ostannard Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72328 2020-01-06T16:33:07+00:00 Simon Tatham simon.tatham@arm.com 2020-01-06T16:33:05+00:00 urn:sha1:4978296cd8e4d10724cfa41f0308d256c0fd490c Summary: The ACLE intrinsics with `gather_base` or `scatter_base` in the name are wrappers on the MVE load/store instructions that take a vector of base addresses and an immediate offset. The immediate offset can be up to 127 times the alignment unit, and it can be positive or negative. At the MC layer, we got that right. But in the Sema error checking for the wrapping intrinsics, the offset was erroneously constrained to be positive. To fix this I've adjusted the `imm_mem7bit` class in the Tablegen that defines the intrinsics. But that causes integer literals like `0xfffffffffffffe04` to appear in the autogenerated calls to `SemaBuiltinConstantArgRange`, which provokes a compiler warning because that's out of the non-overflowing range of an `int64_t`. So I've also tweaked `MveEmitter` to emit that as `-0x1fc` instead. Updated the tests of the Sema checks themselves, and also adjusted a random sample of the CodeGen tests to actually use negative offsets and prove they get all the way through code generation without causing a crash. Reviewers: dmgreen, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72268 2019-12-18T10:13:51+00:00 Sven van Haastregt sven.vanhaastregt@arm.com 2019-12-18T10:13:51+00:00 urn:sha1:308b8b76ceee805c964faf9f2176e3e05532a45b Provide a mechanism to attach OpenCL extension information to builtin functions, so that their use can be restricted according to the extension(s) the builtin is part of. Patch by Pierre Gondois and Sven van Haastregt. Differential Revision: https://reviews.llvm.org/D71476 2019-12-16T18:34:00+00:00 John McCall rjmccall@apple.com 2019-12-16T18:31:44+00:00 urn:sha1:b699fe8b951e14c6a892a58535976c252eb16210 directly to {read,write}UInt32. This will be useful for textual formats. NFC. 2019-12-16T18:34:00+00:00 John McCall rjmccall@apple.com 2019-12-16T08:51:16+00:00 urn:sha1:6887ccfcf283b47f4d7fc58c7099becd79d7c749 This will be required by TemplateName. 2019-12-16T18:34:00+00:00 John McCall rjmccall@apple.com 2019-12-16T07:56:32+00:00 urn:sha1:256ec9964462ea260871f8233ab3923dbdf65497 properties from a value. This is useful when the properties of a case are actually read out of a specific structure, as with TemplateName. 2019-12-16T18:33:59+00:00 John McCall rjmccall@apple.com 2019-12-16T07:10:15+00:00 urn:sha1:efd0dfbd700d724f148468e707b8ba5f28e847e6 This patch doesn't actually use this serialization for anything, but follow-ups will move the current handling of various standard types over to this. 2019-12-16T18:33:59+00:00 John McCall rjmccall@apple.com 2019-12-15T07:39:13+00:00 urn:sha1:00bc76edddb5a6cd417610e96289a5dc15245867 I'm going to introduce some uses of the property read/write methods.