Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use appropriate alignment constraints in LLVM memory model #338

Open
brianhuffman opened this issue Dec 18, 2018 · 4 comments
Open

Use appropriate alignment constraints in LLVM memory model #338

brianhuffman opened this issue Dec 18, 2018 · 4 comments
Labels
subsystem: crucible-llvm Issues related to LLVM bitcode verification with crucible-llvm tech debt Issues that document or involve technical debt topics: memory model Issues that relate to the LLVM and/or Crucible model of pointers and memory blocks type: bug Issues reporting bugs or unexpected/unwanted behavior
Milestone

Comments

@brianhuffman
Copy link
Contributor

Changeset c8c1a54 adapts saw-script to a newer crucible-llvm version that has a new Alignment argument on various memory model operations (see GaloisInc/crucible#117). Currently this argument is set to 0 everywhere (byte-alignment, the minimum) but it would be better to use more alignment whenever possible.

(See also GaloisInc/macaw#20.)

@robdockins
Copy link
Contributor

I needed to increase the alignment of newly-allocated regions so that subsequent loads/stores would not fail. In the doAlloc and doAllocConst functions, we're currently using maxAlignment to make sure that the alignment is sufficient for any primitive type.

It's not 100% clear that this is the right thing to do, as we don't explicitly check the alignment of arguments at call sites, etc. To be really precise about this probably requires adding alignment information to the SAWScript specifications. :-/

In the meantime, perhaps a more reasonable default is to use the alignment value computed for the type of memory object being allocated?

@brianhuffman
Copy link
Contributor Author

After a series of PRs I think we're now using appropriate LLVM alignment values throughout saw-script: #528, #637, #648, #750, and possibly others.

@brianhuffman
Copy link
Contributor Author

brianhuffman commented Jan 18, 2021

On further investigation, it appears that there are a couple of FIXMEs related to alignment remaining in the code.

let alignment = Crucible.noAlignment -- default to byte alignment (FIXME)

let alignment = Crucible.noAlignment -- default to byte alignment (FIXME)

let alignment = Crucible.noAlignment -- default to byte alignment (FIXME, see #338)

let alignment = Crucible.noAlignment -- default to byte alignment (FIXME, see #338)

let alignment = noAlignment -- default to byte-aligned (FIXME)

let alignment = noAlignment -- default to byte-aligned (FIXME)

let alignment = noAlignment -- default to byte-aligned (FIXME)

let alignment = noAlignment -- default to byte-aligned (FIXME)

let alignment = noAlignment -- default to byte-aligned (FIXME)

let alignment = noAlignment -- default to byte-aligned (FIXME)

We should probably leave this ticket open until we take care of each of those.

@brianhuffman brianhuffman reopened this Jan 18, 2021
@brianhuffman brianhuffman added the subsystem: crucible-llvm Issues related to LLVM bitcode verification with crucible-llvm label Jan 18, 2021
@brianhuffman brianhuffman changed the title Take advantage of alignment constraints in LLVM memory model Use appropriate alignment constraints in LLVM memory model Jan 18, 2021
@RyanGlScott
Copy link
Contributor

#1539 will add a couple more uses of noAlignment. I'll edit #338 (comment) once #1539 has landed to include them. I'll also update #1539 so that the comments in saw-script refer back to this issue.

@sauclovian-g sauclovian-g added type: bug Issues reporting bugs or unexpected/unwanted behavior tech debt Issues that document or involve technical debt topics: memory model Issues that relate to the LLVM and/or Crucible model of pointers and memory blocks labels Oct 29, 2024
@sauclovian-g sauclovian-g added this to the Someday milestone Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
subsystem: crucible-llvm Issues related to LLVM bitcode verification with crucible-llvm tech debt Issues that document or involve technical debt topics: memory model Issues that relate to the LLVM and/or Crucible model of pointers and memory blocks type: bug Issues reporting bugs or unexpected/unwanted behavior
Projects
None yet
Development

No branches or pull requests

4 participants