Giter VIP home page Giter VIP logo

Comments (2)

sebastianpoeplau avatar sebastianpoeplau commented on August 27, 2024

The part of the compiler pass that handles expressions for structs is quite involved, as evidenced by the long comment in the function linked in the original issue description. I think it makes sense to try and improve it in general, rather than just adding one more special case. Let's collect the requirements...

  1. Structs in SSA registers are shadowed with expressions describing their in-memory representation. We could alternatively represent a packed or tree view of the structs, but I think doing so would mainly shift the burden of expression conversion from insertvalue/extractvalue to load/store. Moreover, we don't have a way to describe expression trees with a single pointer at the moment.
  2. We need to be able to create expressions for (partially) concrete struct values:
    1. undef
    2. Structs with at least some values in them, plus any number of undef members. Here we need to handle the case where all values are concrete, as well as the case where at least one has a symbolic expression attached to it.

The current implementation handles undef (by creating an all-zeros expression); it also tries to handle structs with values in them but fails, which is the reason for the present bug. This brings us to the last requirement: there should be tests that cover the functionality 🙃

from symcc.

sebastianpoeplau avatar sebastianpoeplau commented on August 27, 2024

It is tempting to describe structs with trees of expressions... For example, the struct type { i8, i32 } could have a shadow type { ptr, ptr } containing expression pointers for individual elements.

The advantage would be that insertvalue/extractvalue wouldn't have to convert expression kinds anymore (e.g., to and from floating-point kind); this would be left to load/store, which already do it anyway. We'd need rather complex logic to handle struct values in load/store which couldn't be in the runtime: it depends on the bitcode type of the value being loaded/stored. However, the same is true for initial expression creation if we express in-memory representations. We could emit conversion functions to/from tree representation when we first encounter the struct type, but I wonder how this would work with literal struct types (i.e., struct types that are defined inline rather than named at top level) 🤔

from symcc.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.