IEEE Std 1076-2008 3. Design entities and configurations, 3.1 General, paragraphs 2 and 3:
A design entity may be described in terms of a hierarchy of blocks, each of which represents a portion of the whole design. The top-level block in such a hierarchy is the design entity itself; such a block is an external block that resides in a library and may be used as a component of other designs. Nested blocks in the hierarchy are internal blocks, defined by block statements (see 11.2).
A design entity may also be described in terms of interconnected components. Each component of a design entity may be bound to a lower-level design entity in order to define the structure or behavior of that component. Successive decomposition of a design entity into components, and binding those components to other design entities that may be decomposed in like manner, results in a hierarchy of design entities representing a complete design. Such a collection of design entities is called a design hierarchy. The bindings necessary to identify a design hierarchy can be specified in a configuration of the top-level entity in the hierarchy.
Hierarchy (structure) is conveyed by internal or external blocks (block statements, or instantiated components or entities). Noting you can declare signals in concurrent generate statements you could use generate statements in the description of you're algorithm, which would produce block statements.
11.2 Block statement, para 1:
A block statement defines an internal block representing a portion of a design. Blocks may be hierarchically nested to support design decomposition.
(And design decomposition means breaking down the design into smaller pieces here).
A process statement doesn't confer hierarchy:
11.3 Process statement, para 1:
A process statement defines an independent sequential process representing the behavior of some portion of the design.
A process statement conveys behavior in sequential statements, which won't likely match what's synthesized. It's a behavioral description not structural.
An elaborated model (14. Elaboration and execution) preserves hierarchy in block statements.
14.2 Elaboration of a design hierarchy, para 5:
Elaboration of a design hierarchy defined by a design entity consists of the elaboration of the block statement equivalent to the external block defined by the design entity. The architecture of this design entity is assumed to contain an implicit configuration specification (see 7.3) for each component instance that is unbound in this architecture; each configuration specification has an entity aspect denoting an anonymous configuration declaration identifying the visible entity declaration (see 7.3.3) and supplying an implicit block configuration (see 3.4.2) that binds and configures a design entity identified according to the rules of 7.3.3. The equivalent block statement is defined in 11.7.3. Elaboration of a block statement is defined in 14.5.2.
14.5.2 Block statements
Elaboration of a block statement consists of the elaboration of the block header, if present, followed by the elaboration of the block declarative part, followed by the elaboration of the block statement part.
An elaborated design model is used as the basis for both simulation and synthesis - the latter not described in the VHDL standard.
So the later conjecture in your question is more accurate, that a VHDL process doesn't convey structure (hierarchy). A process statement describing behavior is subject to logic reduction, and primitive mapping but imposes no hierarchy, which requires ports (signals).
And for practical purposes you can infer post synthesis structure in a process through the use of sequential logic (latches, registers), while combinational logic (processes without a clock edge or wait statement) only have two categories of defined structures - asynchronous ROMs and RAMs.
See IEEE Std 1076.6-2004 (now withdrawn), 6. Modeling hardware elements, paras 1 and 2:
This clause specifies styles for modeling hardware elements such as edge-sensitive storage elements, level-sensitive storage elements, three-state elements, and combinational elements.
This clause does not limit the optimizations that can be performed on a VHDL model. The scope of optimizations that may be performed by a synthesis tool depends on the tool itself. The hardware modeling styles specified in this clause do not take into account any optimizations or transformations. A specific tool may perform optimizations; this may result in removal of redundant or unused logic from the final netlist. This shall NOT be taken as a violation of this standard provided the synthesized netlist has the same functionality as the input model, as characterized in Clause 5.
(Also see the various subclauses.)
A combinational logic process has few hints useful in describing structure and the hardware actually produced isn't otherwise under your control.
There may also synthesis target specific inferences that can be made based on the use of statements (e.g. procedure calls), operators, expressions and numbers of bits (array length). The ability to do that is beyond the scope of VHDL language and the now withdrawn RTL Synthesis standard. The ability to convey structure in this manner is inherently non portable.