Bump LLVM to 3cc852ece438a63e7b09d1c84a81d21598454e1a.

[mikeurbach]

The main difference was in changes related to the APInt constructor.

This was needed when
llvm/llvm-project@3494ee9
landed.

Similar changes were made upstream here:
https://github.com/llvm/llvm-project/pull/80309/files.

Basically, we now expect the width and value arguments to the APInt
constructor to be consistent. There is some implicit extension or
truncation depending on the signedness of the value, and now a flag to
opt into it.

With this change I've simply opted into the flag where necessary,
rather than thinking hard about how to compute the correct width given
the value.

In places where the isSigned flag took the default value of false, I
kept that when I had to explicitly set that flag.

There was exactly one place (CalyxHelpers.cpp), where I actually
flipped the value of isSigned. The comment in the code made me think
this erroneously thought the flag was "isUnsigned".

[cgyurgyik]

Thanks!

[fabianschuiki]

LGTM!

[mikeurbach]

Hmm this is now hitting a compile error related to Python extension, which I didn't see locally with Python 3.10.6. Need to see what got pulled in with this bump that could cause issues here...

[mikeurbach]

I have pinpointed the error to this change upstream: llvm/llvm-project#115307. I think I can fix it by updating to pybind11 2.11.

[mikeurbach]

Wellp, that fixed the compile time failure, but now two handshake tests are failing...

17: INFO cocotb: assert conv_value == res, f"Expected {res}, got {conv_value}" 
18: INFO cocotb: AssertionError: Expected 0.0, got 0000000000000000000000000000000000000000000000000000000000000000 
19: INFO cocotb: assert 0000000000000000000000000000000000000000000000000000000000000000 == 0.0 

Wondering if this is related to the APInt business... I'm setting up icarus verilog and cocotb to try and reproduce.

[mikeurbach]

I checked the types of the cocotb values in the failing test...

(Pdb) type(conv_value)
<class 'cocotb.binary.BinaryValue'>
(Pdb) type(res)
<class 'float'>

I don't know anything about this stuff, but seems like a great time to use the optional converter argument, since the values looked a whole lot like 0s of different types in the failing comparison, so that's what I did in the last commit.

@teqdruid @mortbopet a couple things...

I'm planning to merge this, but if you have any concerns with the most recent commit please take another look here.

I also saw a problem compiling native Python extensions on the version of pybind11 we had on the integration test docker image, so I've bumped that and updated the requirement in our wheel build. I didn't change anything about PyCDE, but it may need a similar update.