search for: expect_true

...ad of optional optimization hints. With %b = i64 call @llvm.expect(i64 %a, i64 16) in the code, %a can still be used, has the same value, but has not the same hint associated with it. To specify a range, I could imagine a @llvm.expect.range intrinsic. Or alternatively, and more general, void @llvm.expect_true(i1 %cond) that is also tracked by AssumptionTracker, but with the difference that when %cond evaluates to false, it is still defined behaviour. Michael

...;llvm/foo.h" for inclusion rather than <llvm/foo.h> * You should use the same format for gtest headers * If reverse iteration isn't supported, you should either have an ASSERT_DEATH() on the decrement, or not have the code there (that's commented out) at all. * Instead of this: EXPECT_TRUE(uintMap[0] == 1); you should use EXPECT_EQ() * Instead of this: EXPECT_TRUE(uintMap.find(0u) == uintMap.begin()); is it possible to use EXPECT_EQ() as well? * In this test: TEST_F(DenseMapTest, IterationTest) { you use the array "int numbers[100];" as an array of booleans; why not make...

Hello, We have some transformations based on SCEV and they usually end-up making heuristic decision based on SCEV comparison. While there are some situations where the comparison is trivial (subtract then look at the sign of the range), there are also a lot of situation where it is not (the range contains 0 strictly [aka. not on the boundary]). And we then take a "default" choice. To

...hould use the same format for gtest headers > > * If reverse iteration isn't supported, you should either have an > ASSERT_DEATH() on the decrement, or not have the code there (that's > commented out) at all. > I'll probably just remove it. > * Instead of this: > EXPECT_TRUE(uintMap[0] == 1); > you should use EXPECT_EQ() > Sure. > * Instead of this: > EXPECT_TRUE(uintMap.find(0u) == uintMap.begin()); > is it possible to use EXPECT_EQ() as well? > In order to use EXPECT_EQ, both arguments have to be printable, although you can make anything prin...

(Forwarding this to llvm-dev) This patch adds a unit test framework to LLVM, along with a sample unit test for DenseMap. I don't expect this patch to be accepted as-is, this is mainly a trial balloon and proof of concept. Some notes about the patch: 1) For the testing framework, I went with Google Test, since it's the one I have the most experience with. I fully expect an extended

...than <llvm/foo.h> > * You should use the same format for gtest headers > > * If reverse iteration isn't supported, you should either have an > ASSERT_DEATH() on the decrement, or not have the code there (that's > commented out) at all. > > * Instead of this: > EXPECT_TRUE(uintMap[0] == 1); > you should use EXPECT_EQ() > > * Instead of this: > EXPECT_TRUE(uintMap.find(0u) == uintMap.begin()); > is it possible to use EXPECT_EQ() as well? > > * In this test: > TEST_F(DenseMapTest, IterationTest) { > you use the array "int numbers[100];&q...

...ivatives = true; > diff --git a/src/glsl/tests/varyings_test.cpp b/src/glsl/tests/varyings_test.cpp > index 4573529..7a962c5 100644 > --- a/src/glsl/tests/varyings_test.cpp > +++ b/src/glsl/tests/varyings_test.cpp > @@ -202,6 +202,33 @@ TEST_F(link_varyings, gl_ClipDistance) > EXPECT_TRUE(is_empty(consumer_interface_inputs)); > } > > +TEST_F(link_varyings, gl_CullDistance) > +{ > + const glsl_type *const array_8_of_float = > + glsl_type::get_array_instance(glsl_type::vec(1), 8); > + > + ir_variable *const culldistance = > + new(mem_ctx) ir...

...than <llvm/foo.h> > * You should use the same format for gtest headers > > * If reverse iteration isn't supported, you should either have an > ASSERT_DEATH() on the decrement, or not have the code there (that's > commented out) at all. > > * Instead of this: > EXPECT_TRUE(uintMap[0] == 1); > you should use EXPECT_EQ() > > * Instead of this: > EXPECT_TRUE(uintMap.find(0u) == uintMap.begin()); > is it possible to use EXPECT_EQ() as well? > > * In this test: > TEST_F(DenseMapTest, IterationTest) { > you use the array "int numbers[100];&q...

...t()); > + } > + // Verify file exists and starts with special header. > + bool MagicMatches = false; > + ASSERT_NO_ERROR(fs::has_magic(Twine(File1), Twine("AABBCCDDEEFFGGHHIIJJ"), > + MagicMatches)); > + EXPECT_TRUE(MagicMatches); > + // Verify file is correct size. > + uint64_t File1Size; > + ASSERT_NO_ERROR(fs::file_size(Twine(File1), File1Size)); > + ASSERT_EQ(File1Size, 8192ULL); > + > + // TEST 2: Verify abort case. > + SmallString<128> File2(TestDirectory); > + File2.a...

...the AsmPrinter. I was able to get simple DWARF to be emitted with the AsmPrinter version of the DWARF generator with code like: initLLVM(); DwarfGen DG; Triple Triple("x86_64--"); StringRef Path("/tmp/test.elf"); bool DwarfInitSuccess = DG.init(Triple, Path); EXPECT_TRUE(DwarfInitSuccess); uint16_t Version = 4; uint8_t AddrSize = 8; DwarfGenCU &CU = DG.appendCompileUnit(Version, AddrSize); DwarfGenDIE CUDie = CU.getUnitDIE(); CUDie.addAttribute(DW_AT_name, DW_FORM_strp, "/tmp/main.c"); CUDie.addAttribute(DW_AT_language, DW_FORM_data...

I now have an implementation of FileOutputBuffer (OutputBuffer was already taken). The patch supports the functionality listed below and I've tested that it works for lld. -------------- next part -------------- A non-text attachment was scrubbed... Name: FileOutputBuffer.patch Type: application/octet-stream Size: 25308 bytes Desc: not available URL:

...DWARF to be emitted with the AsmPrinter version of the DWARF generator with code like: > > > initLLVM(); > DwarfGen DG; > Triple Triple("x86_64--"); > StringRef Path("/tmp/test.elf"); > bool DwarfInitSuccess = DG.init(Triple, Path); > EXPECT_TRUE(DwarfInitSuccess); > uint16_t Version = 4; > uint8_t AddrSize = 8; > DwarfGenCU &CU = DG.appendCompileUnit(Version, AddrSize); > DwarfGenDIE CUDie = CU.getUnitDIE(); > > CUDie.addAttribute(DW_AT_name, DW_FORM_strp, "/tmp/main.c"); > CUDie.addAtt...

...ARF generator with code like: >>> >>> >>> initLLVM(); >>> DwarfGen DG; >>> Triple Triple("x86_64--"); >>> StringRef Path("/tmp/test.elf"); >>> bool DwarfInitSuccess = DG.init(Triple, Path); >>> EXPECT_TRUE(DwarfInitSuccess); >>> uint16_t Version = 4; >>> uint8_t AddrSize = 8; >>> DwarfGenCU &CU = DG.appendCompileUnit(Version, AddrSize); >>> DwarfGenDIE CUDie = CU.getUnitDIE(); >>> >>> CUDie.addAttribute(DW_AT_name, DW_FORM_strp, &qu...

On Wed, Jul 13, 2016 at 04:48:51PM +0200, Sedat Dilek via llvm-dev wrote: > [ CCed all people who were involved in this thread ] > > Hi Tom, > > personally, I am interested to test the prebuilt-toolchains for > Ubuntu/xenial alias 16.04 LTS and Debian/Jessie v8.5.0 AMD64. > The available toolchains are incomplete and thus useless. > > Just as a fact: There is still no

...;>> > >>> > >>> initLLVM(); > >>> DwarfGen DG; > >>> Triple Triple("x86_64--"); > >>> StringRef Path("/tmp/test.elf"); > >>> bool DwarfInitSuccess = DG.init(Triple, Path); > >>> EXPECT_TRUE(DwarfInitSuccess); > >>> uint16_t Version = 4; > >>> uint8_t AddrSize = 8; > >>> DwarfGenCU &CU = DG.appendCompileUnit(Version, AddrSize); > >>> DwarfGenDIE CUDie = CU.getUnitDIE(); > >>> > >>> CUDie.addAttribute(...

This patch series adds the needed support for this extension to the various parts of mesa to finally enable it for nvc0. Dave Airlie (1): glsl: lower cull_distance into cull_distance_mesa Tobias Klausmann (10): glapi: add GL_ARB_cull_distance mesa/main: add support for GL_ARB_cull_distance mesa/prog: Add varyings for arb_cull_distance mesa/st: add support for GL_ARB_cull_distance

...because you have to balance maintainability of the test's code with test coverage, and adding 100 lines to test one API hurts readability more than it helps test coverage. > > Another thing. Often times I find myself writing a function to test a complex condition, like this: > > EXPECT_TRUE(Value, ComplexTest(Value)); > > But then you lose the error message ability to see why the complex test failed. You say this is handled by the matcher infrastructure although I don't see an example, but I'll take your word for it. If so, these matchers seem like an across the board...

A long time ago I suggested that we might want to add gmock to compliment the facilities provided by gtest in LLVM's unittests. It didn't go over well: 1) There was concern over the benefit vs. the cost 2) Also concern about what the facilities would look like in practice and whether they would actually help 3) At the time, I didn't have good, large examples of what these things might